Характеристика этапа внедрения разрабатываемого проекта

Автоматизация бизнес-процессов продажи билетов ООО "Зритель"
Организационная структура управления предприятием Программная и техническая архитектура ИС на предприятии, использование их функциональных возможностей. Обеспечение информационной безопасности Сущность задачи и предметная технология её решения Анализ существующих разработок и выбор стратегии автоматизации «КАК ДОЛЖНО БЫТЬ» Выбор и обоснование стратегии автоматизации задачи Выбор и обоснование способа приобретения ИС для автоматизации задачи Обоснование проектных решений по информационному обеспечению Разработка проекта автоматизации: информационный менеджмент Разработка и описание проекта автоматизации, плана-графика автоматизации и сетевой модели задач Характеристика архитектуры разрабатываемого проекта Характеристика этапа внедрения разрабатываемого проекта Характеристика этапа эксплуатации разрабатываемого проекта и возможных работ Ожидаемые риски на этапах жизненного цикла и их описание Оценка стоимостных параметров проекта автоматизации Информационное обеспечение задачи Характеристика нормативно-справочной, входной и оперативной информации Характеристика результатной информации Формализация расчётов показателей Программное обеспечение задачи Схемы технологического процесса сбора, передачи, обработки и выдачи информации Расчёт показателей экономической эффективности проекта
156303
знака
15
таблиц
20
изображений

2.1.4    Характеристика этапа внедрения разрабатываемого проекта

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

Зачем нужно тестировать промежуточные рабочие продукты? Ответ на этот вопрос заключается в двух положениях:

·                   во-первых, обнаружение ошибок как можно раньше позволяет избавиться от напрасной реализации неправильных решений, от использования неправильных (а потому переделываемых в дальнейшем) компонентов, от обременительных возвратов к уже пройденному;

·                   во-вторых, легче обнаружить и исправить ошибку не в результате следствий из нее, которые сделали противоречие явным, а во время ее появления, когда ошибка не «обросла» многими связями и влияниями на другие компоненты программной системы.

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

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

·                   как для деятельности данного вида определяется период тестирования — время, отводимое для тестирования в плане итерации;

·                   какие кадровые и технические ресурсы требуются для каждого из периодов тестирования;

·                   какие инструменты используются при тестировании данного вида деятельности.

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

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

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

·                   тесты для проверки функциональности;

·                   тесты для проверки корректности преобразований данных;

·                   интерфейсные тесты;

·                   специфичные для данного проекта (итерации) тесты.

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

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

При планировании тестирования для проекта в целом и для каждой итерации устанавливается требуемый уровень качества тестирования: высокий, средний и низкий (возможна и другая градация). Для его задания используются сведения уточненного заказа и соглашения из Концепций развития проекта. Уровень качества тестирования — неформальный показатель, отражающий какое количество ошибок, оставшихся после проведения тестирования, считается допустимым (учитывается, что одни ошибки исправляются на текущей итерации, а другие — в ходе последующих итераций, возможно, в следующих релизах). Этот показатель прямо связывается с выделением времени и других ресурсов, для проведения тестирования, выполнения диагностики и исправления ошибок:

·                   высокий — требует выделения для тестирования времени 95% и более из суммарного времени, отведенного для работ данной итерации;

·                   средний — для тестирования требуется от 20% до 50% из суммарного времени работ данной итерации;

·                   низкий — для тестирования отводится порядка 5% суммарного времени работ данной итерации.

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

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

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

указать причину ошибки;

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

установить когда исправление будет сделано.

С точки зрения распределения ролей исполнителей проекта тестировщик решает только задачу фиксации ошибок, и, вообще говоря, оставляет в стороне задачу диагностики, решение которой — функция проектировщика подсистемы и разработчиков.

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

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



Информация о работе «Автоматизация бизнес-процессов продажи билетов ООО "Зритель"»
Раздел: Информатика, программирование
Количество знаков с пробелами: 156303
Количество таблиц: 15
Количество изображений: 20

Похожие работы

Скачать
120355
31
25

... . 4. Содержание и тех. поддержка Бизнес-портала Содержание и тех. поддержка Бизнес-портала подразумевает непосредственное ведение бизнеса в сети Интернет. Основным источником дохода является предоставление услуг по размещению информации об организациях на бизнес-портале. Второстепенными источниками дохода являются оказание услуг по размещению баннеров на бизнес-портале и созданию WEB-сайтов. Вывод ...

Скачать
446015
2
0

... нац-й культуры, изучение спектра проблем общественного сознания. ü  Материальные вопросы, наличие эк-ких предпосылок для решения возникших проблем.13. Современные проблемы в развитии социально-культурного сервиса и туризма. В РФ необходимо создание тур. комплекса, обеспечивающего, с одной стороны широкими возможностями для удовлетворения потребностей росс. и иностр. граждан в тур. услугах, ...

Скачать
138795
15
12

... резкого снижения уровня доходов творческих работников, оттока в другие сектора экономики и миграции за рубеж; 5.         снижение уровня обеспеченности населения культурными благами. 2 АНАЛИЗ ХОЗЯЙСТВЕННОЙ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЯ 2.1 Краткая организационно- экономическая характеристика Алтайский краевой театр драмы - это старейший театр на Алтае, один из крупнейших театральных ...

Скачать
122831
9
8

... с приобретением и использованием данного ПС за счет экономии ресурсов. Данный раздел содержит характеристики разработки, расчет затрат на разработку, производство и использование «Информационно-справочной системы кинотеатра», вычислительной техники, выбор метода и расчет экономического эффекта. 9.1 Исходные данные Таблица 9.1 – Исходные данные № пп Наименование показателя Единица ...

0 комментариев


Наверх