Требования к технологии и средствам автоматизации разработки сложных программных средств

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

– к объекту разработки на данном этапе – к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой;

– к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;

– к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качество ПС;

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

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

Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209–1992. Стандарт содержит рекомендации по оценке и выбору инструментальных средств, поддерживающих процессы жизненного цикла программных средств, включая процессы управления проектами, процессы разработки и процессы, следующие за разработкой, а также интегральные процессы жизненного цикла ПС. Для оценки и выбора инструментальной среды и CASE–средств стандартом рекомендуется использовать приведенные ниже наборы правил и критериев. Группы критериев в стандарте выделены и сформированы с учетом общих требований стандарта ISO 9126:1991 по оценке качества программных продуктов.

Технологическую среду и CASE–средства стандартом рекомендуется описывать и выбирать в соответствии с показателями:

– соответствие стандартам среды, указанным в списке характеристик и функций, пoддepживaeмыx CASE–средством, включая стандарты на языки, базы данных, репозиторий, коммуникации, графический интерфейс пользователя, документацию, разработку, управление конфигурацией, безопасность, обмен информацией, интеграцию данных, управление или пользовательский интерфейс;

– совместимость с другими инструментальными средствами, включая возможность взаимодействия и/или прямого обмена данными (например, с системами подготовки текстов и другими средствами документирования, базами данных, репозиториями и другими CASE–средствами);

– поддержка конкретных методологий, например, объектно–ориентированного анализа, объектно–ориентированного проектирования, проектирования «сверху–вниз»;

– языковая поддержка, включая языки программирования, языки определения данных, языки структурированных запросов, графические языки;

– ввод и редактирование спецификаций требований к разрабатываемому ПС, включая требования к функциям, данным, интерфейсам, качеству, производительности, среде функционирования, стоимости и планированию;

– языки спецификаций требований – возможность CASE–средств импортировать, экспортировать или редактировать информацию требований, используя формальный язык, контроль непротиворечивости спецификаций и полноты;

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

– прототипирование – возможность проектирования и генерации предварительной версии всей системы или ее части на основе требований и/или проектных данных, имеющихся в распоряжении CASE–средства;

– формирование структуры отчетов, которые будут создаваться разрабатываемой системой.

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

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

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

– реструктуризацию исходного кода: ввод исходного кода в одном или нескольких языках, модифицирование его формата и/или структуры и выдачу файла исходного кода на том же самом языке;

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

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

Требования стандарта к средствам управления проектом сложного ПС включают:

– способность CASE–средства оценивать стоимость, формировать планы и другие показатели проекта по данным, вводимым пользователем;

– управление действиями и ресурсами путем поддержки ввода пользователем данных для планирования проекта, данных о фактических действиях и анализ этих данных, включая планы, ресурсы компьютеров, назначение персонала, бюджет проекта, а также возможность определения условий выполнения проекта;

– управление тестовыми процедурами: возможность поддержки управления действиями по тестированию и тестовыми программами, планирования действий по тестированию, регистрации результатов тестирования, генерации отчетов о состоянии тестируемых программ;

– управление качеством разрабатываемого ПС – ввод и обработка данных о качестве, их анализ и генерация отчетов об управлении качеством;

– управление действиями по корректировке плана проекта, отчетов о проблемах и дефектах, возникших в ходе выполнения проекта.

Управление конфигурацией версий проекта ПС должно обеспечивать:

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

– трассирование модификаций – запись всех модификаций, сделанных в системе при ее разработке или сопровождении;

– управление версиями, возможность записи и выполнения функций управления многократными версиями системы, которые могут иметь общие компоненты;

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

– генерацию выпусков (релизов) ПС и его компонентов, возможность поддержки определения пользователем шагов, необходимых для создания версии и автоматизированного выполнения этих шагов;

– возможности автоматического архивирования элементов данных для последующего поиска и применения.

Поддержка разработки технологической и эксплуатационной документации на комплекс программ и его компоненты по требованиям стандарта IEEE 1209 должна включать:

– редактирование текстов – возможность вводить и редактировать данные в текстовом формате;

– графическое редактирование – ввод и редактирование данных в графическом формате;

– редактирование на базе форм – поддержка ввода и редактирование данных в форме, определенной пользователем;

– возможности настольного издательства для оформления документации;

– контроль соответствия выходных результатов CASE–средства стандартам на документацию ПС;

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

Критерии удобства применения CASE–средства в процессе разработки ПС включают:

– непротиворечивость пользовательского интерфейса, включая размещение и представление экранных элементов, совместно появляющихся на экране, и методы входа пользователя в систему;

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

– адаптируемость CASE–средства силами пользователя к его специфичным потребностям, включая различные наборы символов, разные способы представления символов и графики, разные форматы данных, методы ввода и вывода;

– качество документации CASE–средства, включая полноту, ясность, читаемость, полезность;

– доступность и качество учебных материалов, включая учебные материалы, доступные в режиме on–line, руководства по обучению, курсы обучения и визуальные материалы;

– уровень требований к знаниям пользователя, необходимым для эффективного использования CASE–средства, и легкость работы с CASE–средством как для новичков, так и для опытных пользователей;

– общность пользовательского интерфейса между CASE–средством и другими инструментальными средствами, функционирующими в среде проектируемой системы;

– полноту и качество функций помощи в режиме «help»;

– ясность диагностики – понимаемость и полезность диагностических сообщений, получаемых пользователем;

– приемлемое время отклика – время, требующееся для того, чтобы ответить на запрос пользователя в условиях применяемой операционной среды CASE–средства;

– легкость инсталляции CASE–средства, как первоначальной, таки при последующих изменениях.

Критерии оценки эффективности CASE–средства по требованиям стандарта должны учитывать данные для выполняемых объектов и работ как типичного, так и максимального размера и сложности:

– оптимальные требования к объему внешней, общей памяти, чтобы обеспечить работу с любыми требующимися и/или генерируемыми данными на приемлемом уровне производительности;

– оптимальные требования к объему оперативной памяти, адресуемой центральным процессором, для того, чтобы CASE–средство могло загружаться и функционировать на приемлемом уровне производительности;

– оптимальные требования к процессору для функционирования CASE–средства на приемлемом уровне производительности;

– производительность, измеряемую как время, в течение которого CASE–средство выполняет характерные задачи, например, время ответа на запрос.