Одним из главных отличий просто программы от программного продукта является наличие разнообразной, хорошо подготовленной документации. Чтобы как-то структурировать этот параграф, воспользуемся ГОСТом ЕСПД (Единая Система Программной Документации) еще советских времен, кстати, до сих пор не обновлявшимся [13].
Самым главным документом является ТЗ (Техническое Задание), в котором описываются цели и задачи работы, заказчик и исполнители, технические требования, сроки и этапы, требования секретности, форс-мажорные обстоятельства и правила предъявления результатов. Технические требования, в свою очередь, делятся на функциональные, экономические, требования по надежности, эффективности, защищенности от несанкционированного доступа и др. ТЗ должно быть составлено таким образом, чтобы исключить возможные разночтения, все требования должны быть сформулированы так, чтобы их можно было проверить однозначным образом. Самая главная ошибка начинающих руководителей – это неаккуратно составленное ТЗ или неоднозначные спецификации. В моей практике было много случаев, когда заказчики, пользуясь неопытностью наших руководителей, отказывались от финальных платежей, требовали дополнительных работ или еще каких-то преференций. С другой стороны, при утверждении ТЗ, я как генеральный директор, не могу уследить за всеми деталями, поэтому еще много лет назад взял себе за правило проверять только финансовую сторону договора, а уж если руководитель договора прозевал что-то по технике, то пусть ему это будет уроком. Разумеется, в таком случае пострадает и предприятие, но надо же как-то учить руководителей.
Следующим по важности документом является ПМИ (Программа и Методика Испытаний). Структурно ПМИ подобна ТЗ – практически для каждого пункта ТЗ в ПМИ говорится, как этот пункт будет проверяться. Способы проверки могут быть самыми разными – от пропуска специального теста до изучения исходных текстов программы, но они должны быть предусмотрены заранее, а не придумываться в момент испытаний. Новички приступают к составлению ПМИ непосредственно перед завершением работ, а опытные руководители составляют ПМИ практически одновременно с ТЗ (хотя бы в общих чертах) и согласовывают ее с заказчиками вместе с ТЗ. Именно хорошо составленная ПМИ является гарантией успешной сдачи работ.
Руководство системного программиста, на современном чисто русском языке называется руководством по инсталляции. В нем описывается порядок установки системы на ЭВМ, как проверить корректность поставленной системы, как вносить изменения и т.п. Обычно это простой короткий документ; в противном случае система, наверное, плохая, сделанная непрофессионалами.
Руководство оператора (пользователя) – это, собственно, основной документ, описывающий, как пользоваться системой. В хорошем руководстве сначала описывается идея системы, основные функции и как ими пользоваться, а уже потом идет описание всех клавиш и меню. Многие современные книги по программам Microsoft представляют собой яркие примеры никуда не годных руководств – можно прочесть 100 страниц и не понять основных функций.
Руководство программиста. Часто это самый объемный документ, описывающий внутреннюю организацию программы. Обычно этот документ идет в паре с документом "текст программы" – одностраничный документ с оглавлением дискеты или CD. Руководство программиста дает заказчику возможность дописать какие-то новые фрагменты программы или переделать старые. В современной литературе этот документ называется SDK (Software Development Kit). Продукт, снабженный SDK, может стоить на порядок дороже, чем такой же продукт без оного, так что можно понять, насколько трудно создать действительно полезный SDK. Сейчас не очень принято продавать исходные тексты программ – проблемы с интеллектуальной собственностью, даже при наличии SDK трудно "влезть" в чужую программу – как говорится, себе дороже. Поэтому большое распространение получили API (Application Program Interface). Программа передается только в виде DLL (библиотека двоичных кодов), но известно, как обратиться к каждой функции из других программ, т.е. известно имя точки входа, количество, типы и значения параметров. Наличие множества API, конечно, хуже, чем наличие исходных текстов (например, нельзя переделать что-то в середине функции), зато много проще в использовании. С другой стороны, все большую популярность приобретает
Остальные документы, перечисленные в ЕСПД, носят формальный или необязательный характер, поэтому мы их обсуждать не будем.
Случилось чудо — вам удалось сдать программу, а заказчик начал ее промышленное использование. Вы облегченно вздохнули, обрадовались и, как всегда, рано. Начинается этап сопровождения ", который длится, пока программа живет. В процессе эксплуатации возникают новые требования, всплывают ошибки, объемы обрабатываемых данных растут, соответственно, растут и требования к эффективности. Нравится вам это или нет, "живущую" программу придется все время изменять.
Основными задачами сопровождения являются:
Очень трудно сопровождать программу, в процессе разработки которой о сопровождении никто не думал. Такие простые вещи, как разумные комментарии, выбор идентификаторов и ступенчатое расположение строк исходного текста, заметно облегчают сопровождение, но часто разработчики об этом не заботятся. Только на этапе разработки можно предусмотреть средства для профилирования, снятия трасс, отладочных печатей и т.п. "Программист, который в процессе разработки продукта пользуется отладочными средствами, а перед сдачей программы в промышленную эксплуатацию выкидывает их, похож на человека, который ходит по берегу в спасательном жилете, а, уходя в море, оставляет жилет на берегу".
Важным элементом сопровождения является "горячая линия" – 24 часа в сутки, 7 дней в неделю должен быть доступен специалист (по телефону или по электронной почте), готовый ответить на вопрос, принять замечание, просто поговорить с пользователем, и этому специалисту нужны инструментальные средства для быстрой подготовки ответов. Словом, вопросы сопровождения должны быть предусмотрены при разработке.
Сопровождение – это особое искусство. Старые программы (
Часто бывает, что, исправив одну ошибку, получаешь две других.
Профессиональные организации, получив контракт на сопровождение большой программы, тратят время и деньги на ее изучение, анализ модульной структуры, потоков управления и т.д. Такое действие называется
Особый интерес вызывает вопрос, когда же следует прекращать сопровождение. На этот вопрос отвечает известная диаграмма:
Здесь по горизонтали растет важность программы для бизнеса компании, а по вертикали – сложность внесения исправлений. Так вот, если исправлять несложно, но и важность – небольшая, то надо просто сопровождать, исправляя ошибки (corrective fixing), если же программа важна для компании, то можно и улучшать ее (adaptive fixing). Если исправлять сложно, а важность – небольшая, то легче программу выкинуть, если же программа важна, содержит определенные знания бизнес-процессов, но сопровождать ее трудно, например, потому, что авторы программы покинули компанию или компания вынуждена сменить платформу, то программу следует подвергнуть реинжинирингу [15].
Попросту говоря, реинжиниринг – это перевод программы со старых языков (Кобол, ПЛ1, Адабас-Натурал и т.п.) на новые, такие как Java, Visual Basic, C++. На самом деле, все гораздо сложнее. Смена операционной системы, используемой базы данных, стиля организации диалога с пользователем – каждая из этих задач весьма нетривиальна. Если же добавить естественное желание реструктурировать программу, выкинуть отмершие части, перейти к объектно-ориентированной организации программы и т.д., да еще вспомнить, что все эти задачи требуют перебора и анализа путей в графе управления программы, число которых растет экспоненциально относительно числа вершин, то задача вообще выглядит нерешаемой. Мы потратили на нее много лет по заказу компании Relativity technologies (США, Северная Каролина) и создали продукт Rescueware, который известная консалтинговая компания Gartner Group уже дважды признала лучшим в мире в области
Мы долго ломали голову, как подступиться к этой задаче. Мы все были математиками, поэтому хорошо понимали, почему американские ученые отказались от нее. Но потом сообразили, что в большинстве случаев нам и не нужен полный перебор путей в графе, а в тех случаях, когда без него не обойтись, можно за один перебор решить сразу несколько задач или одну задачу, но сразу для многих переменных. На тему реинжиниринга у нас опубликовано множество работ, все они выложены на сайте кафедры системного программирования.
Чтобы дать хоть какое-то представление о системе Rescueware, перечислим некоторые ее возможности:
Идея BRE очень проста – находите в конце графа программы узлы, где возникают конечные значения нужных функций, и двигаетесь назад, выбирая только те узлы и ребра, которые влияют на промежуточные вычисления уже помеченные, как нужные.
Можно и наоборот – если известно, что из 100 входных данных интересными остаются только 40, а остальными 60 можно пренебречь, можно пройтись по графу программы слева направо аналогичным образом.
Разумеется, на практике все гораздо сложнее — чего стоят одни массивы, в которых разные элементы влияют на разные функции. Тем не менее, нам удалось добиться практически значимых результатов.
Согласно современным международным стандартам, качество программного обеспечения, как и любого другого продукта, – это его соответствие потребностям заказчика [17]. Самый верный путь повысить качество ПО – улучшить процесс создания и сопровождения продукта.
Качество программного обеспечения (программных средств, инструментов, приложений), используемого в коммерческих и государственных структурах, служащего основой всемирной сети и разнообразных информационных систем, является критически важным фактором. Сегодня деятельность многих организаций, предприятий и, особенно, высокотехнологичных компаний напрямую зависит от качественной обработки информации соответствующими компьютерными системами.
Применение некачественного программного обеспечения может привести к серьезным потерям и затратам на восстановление утерянных данных и программной системы в целом. Предприятия наиболее уязвимы в период внедрения и использования новых программных продуктов и информационных систем. Именно в это время ущерб от некачественного программного обеспечения наиболее вероятен.
По данным исследования Тома де Марко (США, 1982 г.):
Проблемы, выявленные в ходе более чем 150 экспериментов по оценке различных программных проектов:
Выдержка из статьи "Software’s Chronic Crisis", появившейся через 12 лет после публикации этого исследования (автор W. Wayt Gibbs, журнал "Scientific American", сентябрь 1994 года): "Исследования показали, что на каждые 6 крупных систем программного обеспечения, запущенных в действие, приходится 2 (т.е. 30-35%) системы, разработка которых была прекращена из-за невозможности добиться удовлетворительного функционирования. Средний проект разработки программного обеспечения затягивается на половину первоначально запланированного срока, крупные проекты – и того хуже. Три четверти всех больших систем либо выполняют не все функции, которые на них возлагались, либо не используются вовсе".
По данным Департамента по Торговле и Промышленности Великобритании (DTI), при внедрении проектов информационных технологий на предприятиях потери из-за некачественного программного обеспечения составляют в среднем около 20% от общего объема потерь. По разным оценкам, аналогичный показатель для России достигает величины от 30 до 50%.
Может показаться, что управлять количеством ошибок в коде невозможно и их число зависит только от способностей конкретного разработчика. Это не совсем так. В конце 80-х – начале 90-х годов в программной индустрии был проведен ряд серьезных исследований эффективности труда программистов.
Вот данные американского института программной инженерии SEI. Профессиональные программисты со стажем 10 и более лет на 1000 строк кода (СК – строка исходного текста, которая содержит программную инструкцию) допускают в среднем 131,3 ошибки. Следовательно, большая система размером миллион СК может содержать 100 тысяч ошибок! Из них до 50% выявляется на этапе компиляции (если транслятор имеет развитую систему предупреждений). На этапе тестирования отдельных модулей (типичный программный модуль по определению SEI содержит от 5 до 5 тысяч СК) обнаруживается половина оставшихся ошибок. Получается, что перед этапами внедрения и комплексного тестирования в продукте еще скрывается 25 тыс. ошибок. На их устранение на заключительных этапах тратится от 10 до 40 человеко-часов на ошибку, т.е. на доведение продукта до идеального состояния потребуется 125 человеко-лет работы!
Другая статистика. Типичный небольшой проект имеет объем 50 тысяч СК. Его создают 5 программистов, делая при этом 100 ошибок на тысячу СК. 50% ошибок выявляется на этапе компиляции с незначительными расходами времени, устранение ошибок на этапе тестирования занимает 90% времени. Стоимость устранения одной ошибки в готовом продукте оценивается в 4 тыс. долл. (по данным IBM, устранение ошибок в продуктах компании, введенных в эксплуатацию, обходится в 20 тысяч долларов на ошибку).
Корень проблемы — в неправильных акцентах при управлении качеством ПО. Корреляция между числом ошибок, обнаруженных при тестировании отдельных модулей, и числом ошибок, найденных пользователями в готовом продукте, равна 0,91. Отсюда вывод – если на тестирование поступит некачественный продукт, он таким и будет выпущен в продажу!
Таким образом, организация производства качественного программного обеспечения является ключевой проблемой управления процессом разработки ПО, которой в индустриально развитых странах стали активно заниматься примерно с середины 1960-х годов. К числу бесспорных достижений теории менеджмента качества относятся современное понятие качества и его смысловое наполнение, а также известные модели систем качества серии ISO 9000.
Анализ известных нормативных документов дает основание предполагать, что при коммерческой эксплуатации программного продукта к числу наиболее значимых показателей качества, базирующихся на обоснованных претензиях пользователей, можно отнести:
Кроме таких "первичных" данных о качестве, идущих непосредственно от потребителя, в роли показателей могут выступать: число строк кода в стандартном модуле, количество выявленных ошибок на 1000 строк кода, вероятность появления специфических ошибок, параметры сложности программы, стоимость единицы кода, цена "человеко-месяца", статистические характеристики процессов (математические ожидания, дисперсии, корреляционные функции и т. д.) и другие оценочные параметры.
Отсюда следует "генеральная" задача разработчика ПО – на основе анализа взаимной корреляции ранжированных потребительских, технологических и технических характеристик создать систему целевых показателей (метрик), которая задает ориентиры разработки и критерии оценки ее качества.
Такая задача трудна даже для искушенного разработчика, однако использование ранее наработанного опыта и знаний, накопленных в межпроектных базах данных и отраженных в корпоративных и международных стандартах, позволяют существенно уменьшить "размерность" задачи.
Ранее было отмечено, что из-за отсутствия адекватных систем управления качеством во многих проектах (особенно крупных) временные и экономические показатели значительно выше запланированных. Но даже превышение показателей не гарантирует выполнения технических требований. Ряд крупных IT-проектов, как в Европе, так и в Америке, не достигли заявленных результатов, будучи не в состоянии реализовать требуемые технические и технологические параметры, хотя отпущенные время и средства были значительно превышены.
Система управления качеством является частью системы управления организацией. Цели в сфере качества дополняют основные (стратегические) задачи организации. Различные части системы управления организации-разработчика могут быть объединены вместе с системой менеджмента качества в единую, унифицированную систему управления с общими элементами. Это способствует эффективному планированию, распределению ресурсов, установлению взаимодополняющих целей и реальной оценке эффективности.
Инициативы внедрения систем качества в широких масштабах в Японии в начале 50-х годов, поддержанные правительственными программами, обеспечили быстрый рост конкурентоспособности и выход страны на лидирующие позиции в ряде областей промышленности. Активное внедрение новых решений, направленных на обеспечение качества, в США и Европе началось в начале 60-х годов.
Если говорить о программировании, то идеи реализации качества на базе создания стандартного процесса разработки и сопровождения ПО пришли в эту область из промышленности в ответ на программный кризис конца 60-х годов [Wheeler Sh., Duggins Sh. Improving
Среди стандартов в области разработки систем качества, оценки качества процессов и уровня зрелости компаний, разрабатывающих программное обеспечение, сегодня наиболее популярными являются: ISO 9000 (версии 1994 и 2000 гг.), ISO 12207, TickIT, SEI
Компьютерная программа представляет собой материальный объект, но она строится на абстрактных идеях и состоит из сложнейших виртуальных конструкций. Это в корне отличает ее от физических объектов, с которыми имеет дело обычное производство, и поэтому невозможно создать качественное ПО, не решив ряд типичных проблем:
В последние годы постепенно сложилась определенная культура, появились традиции и стиль работы в сфере создания программных продуктов.
| Продукт (методики разработки) | Проект (методики менеджмента проектов) | Персонал (методики управления персоналом) | |||
|---|---|---|---|---|---|
| 1 | Определение продукта (состав, клиентская среда и требования) | 1 | Оценка стоимости проекта в целом (как правило, в человеко-месяцах) | 1 | Набор персонала (как правило, на конкурсной основе) |
| 2 | Процессы оценивания (определения критериев) | 2 | Документирование общего и оперативных планов | 2 | Отбор команды проекта и обучение персонала |
| 3 | Оценка альтернативных подходов к реализации продукта | 3 | Оценка трудозатрат в структуре проекта | 3 | Создание команды проекта и распределение ответственности |
| 4 | Управление требованиями | 4 | Оценка и менеджмент рисков | 4 | Оценка потенциальных возможностей участников проекта |
| 5 | Управление субподрядом | 5 | Создание структуры пооперационного перечня работ | 5 | Создание структуры пооперационного перечня работ |
| 6 | Выполнение начальной оценки | 6 | Оценка ключевых стадий и составление графика работ | 6 | Взаимодействие и общение на уровне групп и команды в целом |
| 7 | Отбор инструментов, методов, стандартов, разработка внутренних стандартов | 7 | Отбор инструментов управления проектом | 7 | Обучение проектных команд для получения оптимальных результатов |
| 8 | Настройка процессов на выполнение требований ТЗ | 8 | Знание стандартов процесса и настройка стандартов на процесс | 8 | Эффективное представление и использование навыков |
| 9 | Понимание действий по разработке продукта (полное представление о необходимых действиях в течение всего ЖЦ) | 9 | Формирование метрических показателей для измерения параметров процессов и управления процессами | 9 | Успешное ведение переговоров с внешними и внутренними участниками проекта, совместные обсуждения и оценки |
| 10 | Управление изменениями | 10 | Отслеживание процессов (процессный мониторинг и совершенствование качества) | 10 | Организация эффективных встреч для планирования совместных работ |
| 11 | Отслеживание качества продукта в ходе разработки (мониторинг качества рабочих продуктов) | 11 | Отслеживание процесса разработки (мониторинг соответствия стандартного процесса разработки ПО принятым требованиям) | 11 | Вопросы индивидуальной и коллективной интеллектуальной собственности |
| 12 | Отслеживание хода разработки проекта |
Наилучшие практики, взятые на вооружение ведущими компаниями, образовали так называемые "Тридцать четыре необходимые компетенции для управления программными проектами, стандартизации процесса разработки ПО и реализации его качества".
Эти "компетенции" нашли отражение в большом количестве национальных и корпоративных стандартов разных стран, которые послужили основой для создания нескольких международных стандартов, широко применяемых в настоящее время.
Одним из главных отличий просто программы от программного продукта является наличие разнообразной, хорошо подготовленной документации. Чтобы как-то структурировать этот параграф, воспользуемся ГОСТом ЕСПД (Единая Система Программной Документации) еще советских времен, кстати, до сих пор не обновлявшимся [13].
Самым главным документом является ТЗ (Техническое Задание), в котором описываются цели и задачи работы, заказчик и исполнители, технические требования, сроки и этапы, требования секретности, форс-мажорные обстоятельства и правила предъявления результатов. Технические требования, в свою очередь, делятся на функциональные, экономические, требования по надежности, эффективности, защищенности от несанкционированного доступа и др. ТЗ должно быть составлено таким образом, чтобы исключить возможные разночтения, все требования должны быть сформулированы так, чтобы их можно было проверить однозначным образом. Самая главная ошибка начинающих руководителей – это неаккуратно составленное ТЗ или неоднозначные спецификации. В моей практике было много случаев, когда заказчики, пользуясь неопытностью наших руководителей, отказывались от финальных платежей, требовали дополнительных работ или еще каких-то преференций. С другой стороны, при утверждении ТЗ, я как генеральный директор, не могу уследить за всеми деталями, поэтому еще много лет назад взял себе за правило проверять только финансовую сторону договора, а уж если руководитель договора прозевал что-то по технике, то пусть ему это будет уроком. Разумеется, в таком случае пострадает и предприятие, но надо же как-то учить руководителей.
Следующим по важности документом является ПМИ (Программа и Методика Испытаний). Структурно ПМИ подобна ТЗ – практически для каждого пункта ТЗ в ПМИ говорится, как этот пункт будет проверяться. Способы проверки могут быть самыми разными – от пропуска специального теста до изучения исходных текстов программы, но они должны быть предусмотрены заранее, а не придумываться в момент испытаний. Новички приступают к составлению ПМИ непосредственно перед завершением работ, а опытные руководители составляют ПМИ практически одновременно с ТЗ (хотя бы в общих чертах) и согласовывают ее с заказчиками вместе с ТЗ. Именно хорошо составленная ПМИ является гарантией успешной сдачи работ.
Руководство системного программиста, на современном чисто русском языке называется руководством по инсталляции. В нем описывается порядок установки системы на ЭВМ, как проверить корректность поставленной системы, как вносить изменения и т.п. Обычно это простой короткий документ; в противном случае система, наверное, плохая, сделанная непрофессионалами.
Руководство оператора (пользователя) – это, собственно, основной документ, описывающий, как пользоваться системой. В хорошем руководстве сначала описывается идея системы, основные функции и как ими пользоваться, а уже потом идет описание всех клавиш и меню. Многие современные книги по программам Microsoft представляют собой яркие примеры никуда не годных руководств – можно прочесть 100 страниц и не понять основных функций.
Руководство программиста. Часто это самый объемный документ, описывающий внутреннюю организацию программы. Обычно этот документ идет в паре с документом "текст программы" – одностраничный документ с оглавлением дискеты или CD. Руководство программиста дает заказчику возможность дописать какие-то новые фрагменты программы или переделать старые. В современной литературе этот документ называется SDK (Software Development Kit). Продукт, снабженный SDK, может стоить на порядок дороже, чем такой же продукт без оного, так что можно понять, насколько трудно создать действительно полезный SDK. Сейчас не очень принято продавать исходные тексты программ – проблемы с интеллектуальной собственностью, даже при наличии SDK трудно "влезть" в чужую программу – как говорится, себе дороже. Поэтому большое распространение получили API (Application Program Interface). Программа передается только в виде DLL (библиотека двоичных кодов), но известно, как обратиться к каждой функции из других программ, т.е. известно имя точки входа, количество, типы и значения параметров. Наличие множества API, конечно, хуже, чем наличие исходных текстов (например, нельзя переделать что-то в середине функции), зато много проще в использовании. С другой стороны, все большую популярность приобретает
Остальные документы, перечисленные в ЕСПД, носят формальный или необязательный характер, поэтому мы их обсуждать не будем.
Случилось чудо — вам удалось сдать программу, а заказчик начал ее промышленное использование. Вы облегченно вздохнули, обрадовались и, как всегда, рано. Начинается этап сопровождения ", который длится, пока программа живет. В процессе эксплуатации возникают новые требования, всплывают ошибки, объемы обрабатываемых данных растут, соответственно, растут и требования к эффективности. Нравится вам это или нет, "живущую" программу придется все время изменять.
Основными задачами сопровождения являются:
Очень трудно сопровождать программу, в процессе разработки которой о сопровождении никто не думал. Такие простые вещи, как разумные комментарии, выбор идентификаторов и ступенчатое расположение строк исходного текста, заметно облегчают сопровождение, но часто разработчики об этом не заботятся. Только на этапе разработки можно предусмотреть средства для профилирования, снятия трасс, отладочных печатей и т.п. "Программист, который в процессе разработки продукта пользуется отладочными средствами, а перед сдачей программы в промышленную эксплуатацию выкидывает их, похож на человека, который ходит по берегу в спасательном жилете, а, уходя в море, оставляет жилет на берегу".
Важным элементом сопровождения является "горячая линия" – 24 часа в сутки, 7 дней в неделю должен быть доступен специалист (по телефону или по электронной почте), готовый ответить на вопрос, принять замечание, просто поговорить с пользователем, и этому специалисту нужны инструментальные средства для быстрой подготовки ответов. Словом, вопросы сопровождения должны быть предусмотрены при разработке.
Сопровождение – это особое искусство. Старые программы (
Часто бывает, что, исправив одну ошибку, получаешь две других.
Профессиональные организации, получив контракт на сопровождение большой программы, тратят время и деньги на ее изучение, анализ модульной структуры, потоков управления и т.д. Такое действие называется
Особый интерес вызывает вопрос, когда же следует прекращать сопровождение. На этот вопрос отвечает известная диаграмма:
Здесь по горизонтали растет важность программы для бизнеса компании, а по вертикали – сложность внесения исправлений. Так вот, если исправлять несложно, но и важность – небольшая, то надо просто сопровождать, исправляя ошибки (corrective fixing), если же программа важна для компании, то можно и улучшать ее (adaptive fixing). Если исправлять сложно, а важность – небольшая, то легче программу выкинуть, если же программа важна, содержит определенные знания бизнес-процессов, но сопровождать ее трудно, например, потому, что авторы программы покинули компанию или компания вынуждена сменить платформу, то программу следует подвергнуть реинжинирингу [15].
Попросту говоря, реинжиниринг – это перевод программы со старых языков (Кобол, ПЛ1, Адабас-Натурал и т.п.) на новые, такие как Java, Visual Basic, C++. На самом деле, все гораздо сложнее. Смена операционной системы, используемой базы данных, стиля организации диалога с пользователем – каждая из этих задач весьма нетривиальна. Если же добавить естественное желание реструктурировать программу, выкинуть отмершие части, перейти к объектно-ориентированной организации программы и т.д., да еще вспомнить, что все эти задачи требуют перебора и анализа путей в графе управления программы, число которых растет экспоненциально относительно числа вершин, то задача вообще выглядит нерешаемой. Мы потратили на нее много лет по заказу компании Relativity technologies (США, Северная Каролина) и создали продукт Rescueware, который известная консалтинговая компания Gartner Group уже дважды признала лучшим в мире в области
Мы долго ломали голову, как подступиться к этой задаче. Мы все были математиками, поэтому хорошо понимали, почему американские ученые отказались от нее. Но потом сообразили, что в большинстве случаев нам и не нужен полный перебор путей в графе, а в тех случаях, когда без него не обойтись, можно за один перебор решить сразу несколько задач или одну задачу, но сразу для многих переменных. На тему реинжиниринга у нас опубликовано множество работ, все они выложены на сайте кафедры системного программирования.
Чтобы дать хоть какое-то представление о системе Rescueware, перечислим некоторые ее возможности:
Идея BRE очень проста – находите в конце графа программы узлы, где возникают конечные значения нужных функций, и двигаетесь назад, выбирая только те узлы и ребра, которые влияют на промежуточные вычисления уже помеченные, как нужные.
Можно и наоборот – если известно, что из 100 входных данных интересными остаются только 40, а остальными 60 можно пренебречь, можно пройтись по графу программы слева направо аналогичным образом.
Разумеется, на практике все гораздо сложнее — чего стоят одни массивы, в которых разные элементы влияют на разные функции. Тем не менее, нам удалось добиться практически значимых результатов.
Согласно современным международным стандартам, качество программного обеспечения, как и любого другого продукта, – это его соответствие потребностям заказчика [17]. Самый верный путь повысить качество ПО – улучшить процесс создания и сопровождения продукта.
Качество программного обеспечения (программных средств, инструментов, приложений), используемого в коммерческих и государственных структурах, служащего основой всемирной сети и разнообразных информационных систем, является критически важным фактором. Сегодня деятельность многих организаций, предприятий и, особенно, высокотехнологичных компаний напрямую зависит от качественной обработки информации соответствующими компьютерными системами.
Применение некачественного программного обеспечения может привести к серьезным потерям и затратам на восстановление утерянных данных и программной системы в целом. Предприятия наиболее уязвимы в период внедрения и использования новых программных продуктов и информационных систем. Именно в это время ущерб от некачественного программного обеспечения наиболее вероятен.
По данным исследования Тома де Марко (США, 1982 г.):
Проблемы, выявленные в ходе более чем 150 экспериментов по оценке различных программных проектов:
Выдержка из статьи "Software’s Chronic Crisis", появившейся через 12 лет после публикации этого исследования (автор W. Wayt Gibbs, журнал "Scientific American", сентябрь 1994 года): "Исследования показали, что на каждые 6 крупных систем программного обеспечения, запущенных в действие, приходится 2 (т.е. 30-35%) системы, разработка которых была прекращена из-за невозможности добиться удовлетворительного функционирования. Средний проект разработки программного обеспечения затягивается на половину первоначально запланированного срока, крупные проекты – и того хуже. Три четверти всех больших систем либо выполняют не все функции, которые на них возлагались, либо не используются вовсе".
По данным Департамента по Торговле и Промышленности Великобритании (DTI), при внедрении проектов информационных технологий на предприятиях потери из-за некачественного программного обеспечения составляют в среднем около 20% от общего объема потерь. По разным оценкам, аналогичный показатель для России достигает величины от 30 до 50%.
Может показаться, что управлять количеством ошибок в коде невозможно и их число зависит только от способностей конкретного разработчика. Это не совсем так. В конце 80-х – начале 90-х годов в программной индустрии был проведен ряд серьезных исследований эффективности труда программистов.
Вот данные американского института программной инженерии SEI. Профессиональные программисты со стажем 10 и более лет на 1000 строк кода (СК – строка исходного текста, которая содержит программную инструкцию) допускают в среднем 131,3 ошибки. Следовательно, большая система размером миллион СК может содержать 100 тысяч ошибок! Из них до 50% выявляется на этапе компиляции (если транслятор имеет развитую систему предупреждений). На этапе тестирования отдельных модулей (типичный программный модуль по определению SEI содержит от 5 до 5 тысяч СК) обнаруживается половина оставшихся ошибок. Получается, что перед этапами внедрения и комплексного тестирования в продукте еще скрывается 25 тыс. ошибок. На их устранение на заключительных этапах тратится от 10 до 40 человеко-часов на ошибку, т.е. на доведение продукта до идеального состояния потребуется 125 человеко-лет работы!
Другая статистика. Типичный небольшой проект имеет объем 50 тысяч СК. Его создают 5 программистов, делая при этом 100 ошибок на тысячу СК. 50% ошибок выявляется на этапе компиляции с незначительными расходами времени, устранение ошибок на этапе тестирования занимает 90% времени. Стоимость устранения одной ошибки в готовом продукте оценивается в 4 тыс. долл. (по данным IBM, устранение ошибок в продуктах компании, введенных в эксплуатацию, обходится в 20 тысяч долларов на ошибку).
Корень проблемы — в неправильных акцентах при управлении качеством ПО. Корреляция между числом ошибок, обнаруженных при тестировании отдельных модулей, и числом ошибок, найденных пользователями в готовом продукте, равна 0,91. Отсюда вывод – если на тестирование поступит некачественный продукт, он таким и будет выпущен в продажу!
Таким образом, организация производства качественного программного обеспечения является ключевой проблемой управления процессом разработки ПО, которой в индустриально развитых странах стали активно заниматься примерно с середины 1960-х годов. К числу бесспорных достижений теории менеджмента качества относятся современное понятие качества и его смысловое наполнение, а также известные модели систем качества серии ISO 9000.
Анализ известных нормативных документов дает основание предполагать, что при коммерческой эксплуатации программного продукта к числу наиболее значимых показателей качества, базирующихся на обоснованных претензиях пользователей, можно отнести:
Кроме таких "первичных" данных о качестве, идущих непосредственно от потребителя, в роли показателей могут выступать: число строк кода в стандартном модуле, количество выявленных ошибок на 1000 строк кода, вероятность появления специфических ошибок, параметры сложности программы, стоимость единицы кода, цена "человеко-месяца", статистические характеристики процессов (математические ожидания, дисперсии, корреляционные функции и т. д.) и другие оценочные параметры.
Отсюда следует "генеральная" задача разработчика ПО – на основе анализа взаимной корреляции ранжированных потребительских, технологических и технических характеристик создать систему целевых показателей (метрик), которая задает ориентиры разработки и критерии оценки ее качества.
Такая задача трудна даже для искушенного разработчика, однако использование ранее наработанного опыта и знаний, накопленных в межпроектных базах данных и отраженных в корпоративных и международных стандартах, позволяют существенно уменьшить "размерность" задачи.
Ранее было отмечено, что из-за отсутствия адекватных систем управления качеством во многих проектах (особенно крупных) временные и экономические показатели значительно выше запланированных. Но даже превышение показателей не гарантирует выполнения технических требований. Ряд крупных IT-проектов, как в Европе, так и в Америке, не достигли заявленных результатов, будучи не в состоянии реализовать требуемые технические и технологические параметры, хотя отпущенные время и средства были значительно превышены.
Система управления качеством является частью системы управления организацией. Цели в сфере качества дополняют основные (стратегические) задачи организации. Различные части системы управления организации-разработчика могут быть объединены вместе с системой менеджмента качества в единую, унифицированную систему управления с общими элементами. Это способствует эффективному планированию, распределению ресурсов, установлению взаимодополняющих целей и реальной оценке эффективности.
Инициативы внедрения систем качества в широких масштабах в Японии в начале 50-х годов, поддержанные правительственными программами, обеспечили быстрый рост конкурентоспособности и выход страны на лидирующие позиции в ряде областей промышленности. Активное внедрение новых решений, направленных на обеспечение качества, в США и Европе началось в начале 60-х годов.
Если говорить о программировании, то идеи реализации качества на базе создания стандартного процесса разработки и сопровождения ПО пришли в эту область из промышленности в ответ на программный кризис конца 60-х годов [Wheeler Sh., Duggins Sh. Improving
Среди стандартов в области разработки систем качества, оценки качества процессов и уровня зрелости компаний, разрабатывающих программное обеспечение, сегодня наиболее популярными являются: ISO 9000 (версии 1994 и 2000 гг.), ISO 12207, TickIT, SEI
Компьютерная программа представляет собой материальный объект, но она строится на абстрактных идеях и состоит из сложнейших виртуальных конструкций. Это в корне отличает ее от физических объектов, с которыми имеет дело обычное производство, и поэтому невозможно создать качественное ПО, не решив ряд типичных проблем:
В последние годы постепенно сложилась определенная культура, появились традиции и стиль работы в сфере создания программных продуктов.
| Продукт (методики разработки) | Проект (методики менеджмента проектов) | Персонал (методики управления персоналом) | |||
|---|---|---|---|---|---|
| 1 | Определение продукта (состав, клиентская среда и требования) | 1 | Оценка стоимости проекта в целом (как правило, в человеко-месяцах) | 1 | Набор персонала (как правило, на конкурсной основе) |
| 2 | Процессы оценивания (определения критериев) | 2 | Документирование общего и оперативных планов | 2 | Отбор команды проекта и обучение персонала |
| 3 | Оценка альтернативных подходов к реализации продукта | 3 | Оценка трудозатрат в структуре проекта | 3 | Создание команды проекта и распределение ответственности |
| 4 | Управление требованиями | 4 | Оценка и менеджмент рисков | 4 | Оценка потенциальных возможностей участников проекта |
| 5 | Управление субподрядом | 5 | Создание структуры пооперационного перечня работ | 5 | Создание структуры пооперационного перечня работ |
| 6 | Выполнение начальной оценки | 6 | Оценка ключевых стадий и составление графика работ | 6 | Взаимодействие и общение на уровне групп и команды в целом |
| 7 | Отбор инструментов, методов, стандартов, разработка внутренних стандартов | 7 | Отбор инструментов управления проектом | 7 | Обучение проектных команд для получения оптимальных результатов |
| 8 | Настройка процессов на выполнение требований ТЗ | 8 | Знание стандартов процесса и настройка стандартов на процесс | 8 | Эффективное представление и использование навыков |
| 9 | Понимание действий по разработке продукта (полное представление о необходимых действиях в течение всего ЖЦ) | 9 | Формирование метрических показателей для измерения параметров процессов и управления процессами | 9 | Успешное ведение переговоров с внешними и внутренними участниками проекта, совместные обсуждения и оценки |
| 10 | Управление изменениями | 10 | Отслеживание процессов (процессный мониторинг и совершенствование качества) | 10 | Организация эффективных встреч для планирования совместных работ |
| 11 | Отслеживание качества продукта в ходе разработки (мониторинг качества рабочих продуктов) | 11 | Отслеживание процесса разработки (мониторинг соответствия стандартного процесса разработки ПО принятым требованиям) | 11 | Вопросы индивидуальной и коллективной интеллектуальной собственности |
| 12 | Отслеживание хода разработки проекта |
Наилучшие практики, взятые на вооружение ведущими компаниями, образовали так называемые "Тридцать четыре необходимые компетенции для управления программными проектами, стандартизации процесса разработки ПО и реализации его качества".
Эти "компетенции" нашли отражение в большом количестве национальных и корпоративных стандартов разных стран, которые послужили основой для создания нескольких международных стандартов, широко применяемых в настоящее время.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.