Геоинформационные технологии. Автоматизированные системы сбора и хранения и анализа информации. Основы автоматизированных систем проектно-изыскательских работ в природообустройстве

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

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

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

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

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

В случае же обнаружения ошибок в работе необходим возврат к предыдущим этапам; текущая работа тех, кто ошибся, прерывается. Следствием этого обычно является срыв сроков выполнения как исправляемого, так и нового проектов.

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

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

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

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

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

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

Построение итерационной модели заключается в серии коротких циклов (шагов) по планированию, реализации, изучению, действию.

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

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

Недостатки итерационной модели:

• время жизни каждого этапа растягивается на весь период разработки;

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

• запутанность архитектуры;

• трудности использования проектной документации на стадиях внедрения и эксплуатации вызывают необходимость перепроектирования всей системы.

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

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

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

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

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

 Скачать реферат