Тема 2. Этапы разработки проекта: определение стратегии тестирования и проектирование

⇐ ПредыдущаяСтр 3 из 6Следующая ⇒

· Определение стратегии тестирования

· Проектирование

· Журнал проектирования

· Планирование этапа проектирования

· Перепланирование

· Ранние стадии

· Рассмотрение результатов анализа

· Семинары

· Критические участки

· Оценка ограничений

· Определение целевой архитектуры

· Выделение потенциальных узких мест в информационной системе

· Продукты третьих фирм

· Использование CASE-средств

· Инфраструктура

· Проектирование базы данных

· Построение модели данных

· Создание базы данных для разработчика

· Проектирование процессов и кода

· Выбор средств разработки

· Отображение функций на модули

· Интерфейсы программ

· Интегрирование и наследование механизмов обмена данными

· Определение спецификаций модулей

Определение стратегии тестирования

Как отмечалось ранее, на этапе анализа привлекаются группы тестирования, например для получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения. Кроме того, на данном этапе определяется план работ по обеспечению надежности информационной системы и ее тестирования. Для любых проектов целесообразным является привлечение тестеров на ранних этапах разработки, в частности на этапе анализа и проектирования. Если проектное решение оказалось неудачным и это обнаружено слишком поздно - на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию, - то исправление ошибки проектирования может обойтись очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.

Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

Проектирование

На этапе проектирования формируется модель данных. Проектировщики в качестве исходной информации получают результаты анализа. Конечным продуктом этапа проектирования являются:

· схема базы данных (на основании ER-модели, разработанной на этапе анализа);

· набор спецификаций модулей системы (они строятся на базе моделей функций).

Если проект небольшой, то в качестве аналитиков, проектировщиков и разработчиков могут выступать одни и те же люди. Возникает вопрос: насколько вообще актуальна передача результатов самому себе? Думаем, что актуальна. Представьте себе, что вы передаете данные кому-либо, кто мало знает о системе. Зачастую это помогает, например, найти не описанные вообще, нечетко описанные, противоречиво описанные компоненты системы.

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

Журнал проектирования

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

Такой журнал может вестись как на этапе анализа, так и на этапе разработки и тестирования.

Планирование этапа проектирования

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

· Разбить глобальную задачу на небольшие, независимые задачи. Такими задачами легче управлять, такие задачи легче реализовывать.

· Определить контрольные даты (этапы сдачи), которые позволят определить, насколько успешно продвигается проект, какие направления отстают, какие недогружены, какие работают успешно. Это позволяет обнаружить отставание от сроков сдачи и вовремя предотвратить авралы.

· Определить зависимости между задачами, а также последовательность завершения задач.

· Прогнозировать загрузку персонала, наем временных работников, привлечение других групп разработчиков, привлечение консультантов (если это необходимо).

· Получить четкое представление о том, когда можно начать этап реализации.

· Получить четкое представление о том, когда можно начать этап опытной эксплуатации.

Перепланирование

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

Задачи проектирования.

Ранние стадии

Рассмотрение результатов анализа

Это собственно процесс передачи информации от аналитиков проектировщикам. На практике это интерактивный процесс. У проектировщиков неизбежно будут возникать вопросы к аналитикам, и наоборот. Информация о системе будет постоянно уточняться. При разработке схемы базы данных может измениться информационная модель, полученная на этапе анализа, например, потому, что имеющееся проектное решение нестабильно либо медленно работает при реализации его посредством выбранной СУБД или в силу иных причин. Проверить, охватывает ли анализ все бизнес-процессы системы (то есть, осуществить проверку на полноту), проектировщики не в состоянии, но проверку информационной модели на непротиворечивость и корректность проектировщики провести могут. Это позволяет отследить ошибки в информационной модели и не повторить их в модели данных. Если результаты хранятся в репозитарии CASE-средства, то такая проверка на корректность может быть произведена автоматически.

Семинары

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

Критические участки

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

Часто на этапе проектирования выявляются критические участки, которые не были очевидными на этапе анализа. Это влечет за собой необходимость уточнения информационной модели. Часто это связано с особенностями реализации тех или иных возможностей в выбранной СУБД. Некоторые функции, которые на этапе анализа выглядят простыми, могут стать очень сложными, когда дело дойдет до физической реализации. Например:

· В выбранной СУБД отсутствует эффективный механизм сканирования деревьев, а при анализе выявлено большое количество справочников и выбраны интерфейсы представления в виде деревьев, кроме того, это понравилось заказчику, а СУБД при большом справочнике работает слишком медленно.

· Другая распространенная неприятность - неполно реализованная ссылочная целостность. В СУБД не реализованы каскадные модификации, в информационной модели нормализованные отношения предполагают наличие каскадных удалений и обновлений. Реализация же таких механизмов посредством триггеров оказалась слишком медленной, и уровень каскадирования триггеров ниже, чем уровень каскадных операций, определенных в информационной модели.

Такие моменты могут инициировать не только изменение информационной модели, но и смену СУБД.

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

Оценка ограничений

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

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

Если проект является расширением или модернизацией существующей информационной системы, то число унаследованных ограничений также может быть большим. На этапе проектирования осуществляется обязательная проверка требований к информационной системе в свете выявленных ограничений. Менять платформу, операционную систему или СУБД на этапе реализации сложно, а на этапе опытной эксплуатации практически невозможно (на это просто не хватит времени, если не произойдет чудо). Чем большее количество компонентов системы уже реализовано, тем сложнее произвести подобную замену. Большинство СУБД сейчас работают на нескольких аппаратных платформах и нескольких операционных системах, но если есть участки кода проекта, зависимые от операционной системы или аппаратной платформы, то их изменение может обойтись очень дорого. В данной статье мы не будем обсуждать вопросы переносимости кода, поскольку они выходят за рамки этого цикла.

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

⇐ Предыдущая 1 234 5 6 Следующая ⇒