ИГА. Понятие базы данных
 Скачать 0.77 Mb.
|
Стратегии конструирования программного обеспечения.Существуют 3 стратегии конструирования ПО: однократный проход (водопадная стратегия) - линейная последовательность этапов конструирования; инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система; эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1.1.
Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте - более сложные возможности редактирования и документирования; в 3-м инкременте - проверку орфографии и грамматики; в 4-м инкременте - возможности компоновки страницы. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.  Рис. 1.4. Инкрементная модель Забегая вперед, отметим, что современная реализация инкрементного подхода - экстремальное программирование ХР (Кент Бек, 1999) [10]. Оно ориентировано на очень малые приращения функциональности Критерии качества программ по стандартам ISO (ГОСТ Р ИСО/МЭК 9126-93)Международная организация стандартизации разработала систему стандартов ISO 9001, которые регламентируют вопросы управления качеством. Эти стандарты применимы практически ко всем областям производства товаров и услуг, в частности и к программному обеспечению. В книге так определяется соотношение между моделью СММ и стандартом ISO 9001: «ISO 9001 используется как структура, тогда как СММ определяет детали требований к процессу разработки для включения их в документы по управлению качеством». Россия, являясь членом МОС, приняла стандарт ISO 9001 как свой национальный стандарт. ВНИИ стандартизации выпустил перевод его на русский язык. Целью стандарта является построение системы сквозного управления качеством (TQM — Total Quality Management ). Эта система должна обеспечивать качество на всех этапах разработки. Имеются процедуры сертификации организаций на соответствие стандарту. Прохождение этой сертификации достаточно сложное, однако многие компании стремятся ее пройти. Официальная сертификация на соответствие стандарту дает существенные конкурентные преимущества. При выборе исполнителя заказчик будет уверен в высоком качестве выполнения работ. Некоторые крупные компании при проведении конкурсов и тендеров на работы требуют предоставить информацию о том, как участвующие в конкурсе компании соответствуют стандарту ISO 9001. ISO 9001 определяет минимальный набор требований к управлению качеством. Условно этот набор разбивается на три части: требования к менеджменту компании, к контролю продукции и к процессу разработки. Управление компанией. Эффективная система качества невозможна, если менеджмент компании не осознает ее значения и не ставит ясной цели ее построить. От руководства компании требуется подписать формальное письмо, подтверждающее приверженность поддержанию высокого качества продуктов и услуг, где указываются основные документы, которых следует придерживаться при контроле качества. Руководство компании составляет организационную структуру компании, обеспечивающую контроль качества. Кроме того, определяются процедуры периодических проверок и обсуждений эффективности системы управления качеством. Управление продукцией. Управление продукцией включает контроль за версиями систем, за приобретением готовых пакетов и программ, управлением продукцией, которая в настоящий момент не отвечает требованиям качества. Многие положения стандарта в разделе управления продукцией не относятся к программному обеспечению или являются второстепенными (например, упаковка и хранение). Управление разработкой. Управление процессом разработки — важнейшая часть стандарта 9001 для программистских организаций. Она включает в себя требования по построению и документированию всего процесса разработки программного обеспечения — от заключения контракта до распространения готового продукта (здесь, кстати, управление разработкой переходит в управление продукцией, упоминавшееся ранее). По классификации ISO 9001 разработка программ относится к так называемым «специальным» процессам — таким процессам, в которых дефекты продукта этого процесса могут быть незаметны до тех пор, пока им не начнут пользоваться. Следует отметить, что стандарт 9001 не регламентирует сам процесс разработки, который может быть совершенно различен в различных организациях. Он стандартизует критерии соответствия процесса требованиям сквозного контроля качества. Первым необходимым условием является наличие документации, регламентирующей конкретный процесс в конкретной организации. Можно выделить несколько основных критериев оценки качества программного обеспечения: 1. Качество исходного кода. Соответствие кода стандартам; Легкость поддержки; Малое число предупреждений при компиляции. 2. Качество программного продукта. Функциональность; Надежность; Удобство использования/Практичность; Эффективность; Сопровождаемость . Мобильность. Становится понятно, что предъявляемые требования должны удовлетворять потребностям, как разработчиков программного обеспечения, так и его пользователей. Функциональность (functionality) ПС — это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Этот набор определяется во внешнем описании ПС. Легкость применения (easy of use) ПС — это характеристики ПС, позволяющие минимизировать усилия пользователя ПС подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывающие положительные эмоции определенного или подразумеваемого пользователя. Эффективность (efficiency) ПС — это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов. Сопровождаемость (maintainability) ПС — это характеристики ПС, которые позволяют минимизировать усилия ПС внесению изменений для устранения в нем ошибок и ПС его модификации в соответствии с изменяющимися потребностями пользователей. Мобильность (portability) ПС — это способность ПС быть перенесенным из одной среды применения в другую, в частности, с одного компьютера на другой. Функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности будет красной нитью проходить ПС всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС. Важным аспектом является проверка предъявляемых требований, их полнота и правильность оценки результатов. Для оценки качества могут применяться различные методы: тестирование (модульное, интеграционное, системное, регрессионное); статический анализ кода; динамический анализ кода; просмотр исходных кодов программы (обзор кода). Полученные с их помощью метрики характеризуют различные параметры: быстродействие программы, потребляемые ресурсы (оперативная память, загрузка процессора и т.д.), соответствие стандартам кодирования, количество ошибок на единицу строк кода и многое другое. Тестировать необходимо все параметры, к которым предъявляются требования. Немаловажно отметить, что проверка качества программного обеспечения должна проводиться на всех этапах жизненного цикла. Это обеспечит максимальное качество разрабатываемого программного кода и как результат конечного программного продукта. Нельзя начать разрабатывать некачественный программный продукт, и задуматься о его качестве уже перед завершением разработки. |