Составители:
Рубрика:
14
Здесь потенциально могут быть заложены любые схемы контроля
эффективности системы на протяжении ее жизненного цикла, хотя на
практике столь гибкое использование этого стандарта не встречается.
ГОСТ 34 предусматривает испытания системы на соответствие ТЗ,
анализ их результатов и устранение выявленных недостатков. Таким
образом, если в ТЗ требования к эффективности и ее контролю были
включены в ясно определенной форме и детальном изложении, то хотя бы
при приемке заказчик имеет основания настаивать на испытаниях всех
характеристик АС, определяющих ее эффективность. К сожалению, в
основном серьезные проверки сдвигаются на самый конец работ, а при
испытаниях чаще проверяется только функционал, работоспособность
системы, возможно, вместе с документацией, показателями
производительности, надежности и эргономичности. Однако есть и другие,
более принципиальные недостатки схемы действий, предусматриваемой
старыми стандартами, например:
− по ГОСТ 34 проводится сравнение на соответствие требованиям к
системе, содержащимся в ТЗ, а не потребностям пользователей,
которые как бы «остаются за бортом»;
− с момента разработки концепции и ТЗ до сдачи АС проходит
значительное время, за которое многое может измениться — от
нормативной базы до состава ключевых заинтересованных лиц, а
испытания и сравнения делаются на соответствие требованиям к АС,
составленным на основе прежних потребностей и условий
(используемых технологий, ограничений и т. п.).
Таким образом, нередки случаи, когда изготавливается, успешно (!)
испытывается и принимается в эксплуатацию система, уже ставшая
неэффективной, даже просто ненужной. И тем не менее, как указывалось
выше, в рамках ГОСТ 34 более гибкая организация работ с
эффективностью потенциально вполне возможна.
1.5. Особенности работы с эффективностью в рамках «новых»
стандартов инжиниринга ПО и систем ИСО/МЭК 12207 и
ИСО/МЭК 15288
Уже первые редакции стандартов ([6] и [7]) дали заказчикам большие
дополнительные возможности по обеспечению эффективности систем.
В версиях 2008 г. произведен ряд уточнений, однако основные правила
обеспечения эффективности АС и ИС сохранились. Дадим общую картину
отличий работы с эффективностью по новым стандартам.
1. Отсутствие термина «эффективность системы» в указанных
стандартах. В новых стандартах данный термин в явной форме не
вводится и в тексте активно не используется. Вместо этого на всем
пространстве стандартов говорится об эквивалентных свойствах
15
системы — соответствии потребностям заинтересованных лиц,
определенным на их основе требованиям к системе, ограничениям на её
создание и эксплуатацию. При этом используются указания на отдельные
аспекты потребностей, требований и ограничений: например, затраты на
создание системы или риски при ее создании и использовании. Свои
трудности может создавать уже то, что не определяется формальный
состав документа, аналогичного ТЭО, не упоминается ничего подобного
«экономической» или «социальной» эффективности, но это — далеко не
самая большая трудность в применении новых стандартов.
2. Работа в контексте предприятия (организации). Новые
стандарты предусматривают процесс «Управление портфелем проектов», в
рамках которого принимаются решения:
− об отборе тех инициатив, в реализацию которых будут вкладываться
ресурсы предприятия, и о переходе к запуску соответствующих
проектов и их финансировании;
− о продолжении, переориентации или прекращении каждого из
идущих проектов.
Решения принимаются в зависимости от того, насколько велика
предполагаемая или обнаруживаемая эффективность создаваемой системы,
а также насколько рискован предлагаемый проект и насколько удачно он
идет. Этот процесс для заказчиков (предприятий) — и возможность, и
затруднение одновременно. Дело в том, что многие предприятия находятся
на самых начальных уровнях зрелости организации работ по управлению
инвестициями в ИТ. От этого состояния до способности осмысленно
управлять портфелем проектов и программ — большой путь. Конечно же,
это не означает отказа от сравнительного определения эффективности.
Наоборот, полезно как можно раньше начинать работать с определением
эффективности отдельных систем, чтобы переходить к определению их
приоритетов и вовремя пересматривать состав портфеля.
3. Процесс приобретения и контракты. В том случае, если
необходимость и полезность системы подтверждена, возможность
финансирования ее создания или покупки и внедрения обнаружена и
система включена в портфель поддерживаемых проектов, имеет смысл
говорить о контракте (или нескольких контрактах), в рамках которого
будет непосредственно обеспечиваться эффективность целевой системы.
(Здесь мы не будем рассматривать другие формы соглашений,
допускаемые новыми стандартами.) Для этих целей стандартами
предусмотрен «Процесс приобретения», в ходе которого:
− определяются цели и стратегия приобретения, критерии
соответствия приобретаемой системы (или программного продукта,
или сервиса) потребностям, требованиям и ограничениям;
Страницы
- « первая
- ‹ предыдущая
- …
- 6
- 7
- 8
- 9
- 10
- …
- следующая ›
- последняя »
