Качество программного обеспечения, его характеристики и атрибуты

o Зрелость, завершенность (maturity). - Величина, обратная частоте отказов ПО. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени.

o Устойчивость к отказам (fault tolerance). - Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением.

o Способность к восстановлению (recoverability). - Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы.

o Соответствие стандартам надежности (reliability compliance). - Этот атрибут добавлен в 2001 году.

o Понятность (understandability). - Показатель, обратный к усилиям, которые затрачиваются пользователями на восприятие основных понятий ПО и осознание их применимости для решения своих задач.

o Удобство обучения (learnability). - Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с ПО.

o Удобство работы (operability). - Показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО.

o Привлекательность (attractiveness). - Способность ПО быть привлекательным для пользователей. Этот атрибут добавлен в 2001 году.

o Соответствие стандартам удобства использования (usability compliance). - Этот атрибут добавлен в 2001 году.

o Временная эффективность (time behaviour). - Способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время.

o Эффективность использования ресурсов (resource utilisation). - Способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр.

o Соответствие стандартам производительности (efficiency compliance). - Этот атрибут добавлен в 2001 году.

o Анализируемость (analyzability) или удобство проведения анализа. - Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий.

o Удобство внесения изменений (changeability). - Показатель, обратный трудозатратам на выполнение необходимых изменений.

o Стабильность (stability). - Показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений.

o Удобство проверки (testability). - Показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам.

o Соответствие стандартам удобства сопровождения (maintainability compliance). - Этот атрибут добавлен в 2001 году.

Иногда эта характеристика называется в русскоязычной литературе мобильностью. Однако термин "мобильность" стоит зарезервировать для перевода "mobility" — способности ПО и компьютерной системы в целом сохранять работоспособность при ее физическом перемещении в пространстве.

o Адаптируемость (adaptability). - Способность ПО приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных.

o Удобство установки (installability). - Способность ПО быть установленным или развернутым в определенном окружении.

o Способность к сосуществованию (coexistence). - Способность ПО сосуществовать с другими программами в общем окружении, деля с ними ресурсы.

o Удобство замены (replaceability) другого ПО данным. - Возможность применения данного ПО вместо других программных систем для решения тех же задач в определенном окружении.

o Соответствие стандартам переносимости (portability compliance). - Этот атрибут добавлен в 2001 году.

Перечисленные атрибуты относятся к внутреннему и внешнему качеству ПО согласно ISO 9126. Для описания качества ПО при использовании стандарт ISO 9126-4 [4] предлагает другой, более узкий набор характеристик.

· Эффективность (effectiveness). - Способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

· Продуктивность (productivity). - Способность ПО предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов.

· Безопасность (safety). - Способность ПО обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде.

· Удовлетворение пользователей (satisfaction). - Способность ПО приносить удовлетворение пользователям при использовании в заданном контексте.

Помимо перечисленных характеристик и атрибутов качества, стандарт ISO 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик.

· Полнота реализации функций — процент реализованных функций по отношению к перечисленным в требованиях. Используется для измерения функциональной пригодности.

· Корректность реализации функций — правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности.

· Отношение числа обнаруженных дефектов к прогнозируемому. Используется для определения зрелости.

· Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости.

· Отношение числа доступных проектных документов к указанному в их списке. Используется для измерения удобства проведения анализа.

· Наглядность и полнота документации. Используется для оценки понятности.

Перечисленные характеристики и атрибуты качества ПО позволяют систематически описывать требования к нему, определяя, какие свойства ПО по данной характеристике хотят видеть заинтересованные стороны. Таким образом, требования должны определять следующее.

· Что ПО должно делать, например:

o позволять клиенту оформить заказы и обеспечить их доставку;

o обеспечивать контроль качества строительства и отслеживать проблемные места;

o поддерживать нужные характеристики автоматизированного процесса производства, предотвращая аварии и оптимальным образом используя имеющиеся ресурсы.

· Насколько оно должно быть надежно, например:

o работать 7 дней в неделю и 24 часа в сутки;

o допускается неработоспособность в течение не более 3 часов в год;

o никакие введенные пользователями данные при отказе не должны теряться.

· Насколько им должно быть удобно пользоваться, например:

o покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты;

o инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы.

· Насколько оно должно быть эффективно, например:

o поддерживать обслуживание до 10000 запросов в секунду;

o время отклика на запрос при максимальной загрузке не должно превышать 3 с;

o время реакции на изменение параметров процесса производства не должно превышать 0.1 с;

o на обработку одного запроса не должно тратиться более 1 MB оперативной памяти.

· Насколько удобно должно быть его сопровождение, например:

o добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

o добавление поддержки нового этапа процесса производства не должно стоить более $20000.

· Насколько оно должно быть переносимо, например:

o ПО должно работать на операционных системах Linux, Windows XP и MacOS X;

o ПО должно работать с документами в форматах MS Word 97 и HTML;

o ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000, HTML, RTF и в виде обычного текста;

o ПО должно сопрягаться с существующей системой записи данных о заказах.

Приведенные атрибуты качества закреплены в стандартах, но это не значит, что они вполне исчерпывают понятие качества ПО. Так, в стандарте ISO 9126 отсутствуют характеристики, связанные с мобильностью ПО (mobility), т.е. способностью программы работать при физических перемещениях машины, на которой она работает. Вместо надежности многие исследователи предпочитают рассматривать более общее понятие добротности (dependability), описывающее способность ПО поддерживать определенные показатели качества по основным характеристикам (функциональности, производительности, удобству использования) с заданными вероятностями выхода за их рамки и определенным максимальным ущербом от возможных нарушений. Кроме того, активно исследуются понятия удобства использования, безопасности и защищенности ПО, — они кажутся большинству специалистов гораздо более сложными, чем это описывается данным стандартом.

13. Управление процессом разработки программного обеспечения: задачи, особенности.

Задачи управления проектами

Эта лекция посвящена управлению проектами по разработке, поддержке или модификации программного обеспечения. С достаточно общих позиций можно считать задачей управления проектами эффективное использование ресурсов для достижения нужных результатов. Всегда нужно получить как можно более хорошие результаты, используя при этом как можно меньше ресурсов. При этом в первую очередь возникают два вопроса: что именно считается "хорошим" результатом проекта и чем, какими ресурсами, можно пользоваться для его достижения.

Чтобы ответить на вопрос о том, какими критериями руководствуются при оценке проектов, и чего нужно добиваться, надо рассмотреть его с разных аспектов.

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

С более общих позиций, и экономические, и неэкономические показатели результативности проекта объединяют в понятие ценностей, создаваемых в его ходе. Эти ценности могут иметь различную природу в зависимости от проекта, от организации, в рамках которой он проводится, от национально-культурных особенностей рынка и персонала и пр. Кроме того, ценности выстраиваются в иерархию в зависимости от уровней рассмотрения проектов.

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

В то же время, могут быть получены и другие ценности: достигнута высокая сплоченность команды; новые члены коллектива приобретут серьезные знания и полезные навыки; команда овладеет новыми технологиями; ее члены получат повышение и/или поощрения, которые повысят их лояльность компании и т.п.

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

В одном проекте работа иногда ведется по принципу "сдали и забыли", т.е. основные усилия направлены на то, чтобы заказчик подписал акт приемки работ или его аналог, после чего поставщик перестает отвечать за результаты, поэтому часто такой аспект качества ПО, как удобство внесения изменений, игнорируется. Однако для бизнеса организации в целом проведение таких проектов небезопасно. Среди исследователей и экспертов-практиков преобладает взгляд на любую программную систему как на систему развивающуюся, полезность которой значительно снижается, если нет возможности расширять ее, тем более — исправлять серьезные ошибки, которые всегда есть в сложных программах. Заказчик всегда сталкивается с проблемами поддержки ПО и рано или поздно столкнется и с необходимостью его развития. На уровне группы проектов игнорирование удобства модификации ПО, а также вопросов, связанных с организационными и экономическими последствиями из менений в общей архитектуре, просто губительно.

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

Разработка программного обеспечения (ПО) представляет собой сложную систему взаимосвязи различных процессов реализации проекта. Сюда следует отнести работу с требованиями, предъявляемыми к конечному продукту, работу с техническими рисками реализации проекта, комплекс мер по обеспечению и управлению качеством, а также другие процессы, которые возникают в процессе разработки или имеют место в свете используемой политики проекта организации. Каждый процесс имеет свои специфические особенности, которые также могут быть регламентированы внутренней политикой организации. Это позволяет говорить о том, что каждая организация обладает огромнейшим управленческим потенциалом, от которого на определенном проекте зависит как наличие тех или иных процессов разработки, их специфики, так и конечный результат их выполнения. Успешное завершение каждого процесса разработки ПО может гарантировать более высокое качество конечного продукта, большую экономическую отдачу (выгоду), повышение уровня зрелости, как проекта, так и организации в целом.
Формирование совокупности процессов разработки ПО и управление ими в отдельности и всей их совокупностью в целом позволяет определить в качестве ключевых факторов политики временное дифференцирование узкого набора задач и приоритизацию каждой задачи. При этом понятие приоритизации предлагается рассматривать гораздо шире, поскольку система назначения и управления приоритетами может распространяться как на крупные задачи, так и на более мелкие подзадачи, а также целые процессы со всеми составляющими их механизмами реализации. Что касается временного дифференцирования, то данный фактор политики управления разработкой ПО предлагается рассматривать в рамках одной итерации, поскольку количество итераций программного обеспечения зачастую стремится к бесконечности, а временные рамки при этом должны быть унифицированы в соответствии со стратегией развития проекта.

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

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

Чтобы стало более понятно, о чем идет речь, для начала я постараюсь дать общую картину производства в области разработки и сопровождения ПО в компаниях, профиль которых не связан напрямую с разработкой ПО.

Описание специфики разработки и сопровождения внутреннего ПО в небольшой компании - не разработчике ПО

Большое число задач (более половины) связано с сопровождением, поддержкой и доработкой существующего ПО;

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

Разработка и сопровождение ведется небольшой группой специалистов, а зачастую и вообще одним человеком;

Как следствие, отсутствует явное разделение ролей в процессе: один и тот же человек может совмещать позиции разработчика, аналитика, архитектора, тестера, системного администратора, менеджера проектов и т.д.;

Проекты чаще всего не выходят за рамки внутреннего использования.

Как следствие, процесс разработки ПО в таких компаниях в силу объективных причин достаточно примитивен. Многие технологические процессы отсутствуют или присутствуют в сильно упрощенном варианте. Тем не менее, и такими процессами необходимо управлять и гарантировать приемлемое качество их выполнения.

Общие рекомендации по организации процесса разработки

Прежде, чем озаботиться созданием основ технологии, необходимо по максимуму решить все организационные проблемы. В литературе часто рассматривается вопрос организации рабочей среды в компании-разработчике ПО, однако, для компании, в которой отдел разработки совсем небольшой (1-3 человека), многие из этих рекомендаций покажутся излишними. Тем не менее, таким компаниям рекомендации нужны не меньше. Из своего опыта я могу рекомендовать следующее:

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

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

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

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

5. И вообще, никогда ни при каких обстоятельствах не привлекайте разработчиков к неквалифицированному труду
Если вы, конечно, не боитесь потерять разработчика. Помните, разработчик чрезвычайно ценит свою квалификацию. Хороший разработчик всегда сможет найти себе новую работу, а вы вряд ли легко найдете нового разработчика. Это в крупных организациях с развитым процессом разработки разработчика можно заменить без значительных затрат - а в такой небольшой компании, которая описывается здесь, разработчик может быть единственным носителем знаний о функционирующих программных продуктах, или вообще их единственным автором.

6. Считайте и учитывайте занятость разработчика
В изменяющемся мире бизнеса, например, в телекоммуникационном бизнесе, число задач, связанных с поддержкой существующих систем остается примерно постоянным. Небольшие изменения в существующем ПО требуются регулярно. В процессе разработки нового ПО число систем, которые необходимо сопровождать, растет. Что получается? Суммарное число задач растет со временем. Если разработчик говорит, что он перестает справляться с объемом задач, скорее всего это так. Возьмите еще одного человека, либо закажите разработку и сопровождение части ПО другим организациям.

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

8. В конце концов, создайте документ, описывающий организационную структуру предприятия
Какой бы небольшой ни была ваша компания, такой документ просто необходим. Как минимум, он необходим разработчику, для того, чтобы знать, с кем контактировать по какому вопросу

Выделение основных процессов

Когда организационные проблемы решены на достаточном уровне, можно сконцентрироваться на процессе разработки.

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

Мое мнение состоит в том, что основная рекомендация, которую здесь можно дать, звучит так: "Ничего лишнего". Если вы имеете возможность начать с малого, формализуйте только те процессы, которые можете формализовать и создавайте только те документы, которые будут использоваться.

Наиболее вероятно, что вы сможете выделить следующие процессы: