Сложность параллельного ведения работ. Отмеченные выше проблемы возникаютвследствие того, что работа над проектом строится в виде цепочки последовательныхшагов. Причем даже в том случае, когда разработку некоторых частей проекта(подсистем) можно вести параллельно, при использовании каскадной схемы распараллеливаниеработ весьма затруднительно. Сложности параллельного веденияработ связаны с необходимостью постоянного согласования различных частейпроекта. Чем сильнее взаимозависимость отдельных частей проекта, тем чаще итщательнее должна выполняться синхронизация, тем сильнее зависимы друг отдруга группы разработчиков. Поэтому преимущества параллельного ведения работпросто теряются.Отсутствие параллелизма негативно сказывается и на организации работы всегоколлектива разработчиков. Работа одних групп сдерживается другими. Покапроизводится анализ предметной области, проектировщики, разработчики и те,кто занимается тестированием и администрированием, почти не имеют работы.Кроме того, при последовательной разработке крайне сложно внести измененияв проект после завершения этапа и передаче проекта на следующую стадию.Так, например, если после передачи проекта на следующий этап группаразработчиков нашла более эффективное решение, оно не может быть использовано.Это связано с тем, что более раннее решение уже, возможно, реализовано исвязано с другими частями проекта. Поэтому исключается (или, по крайней мере,существенно затрудняется) доработка проекта после его передачи на следующийэтап.
Информационная перенасыщенность. Проблема информационной перенасыщенностивозникает вследствие сильной зависимости между различными группамиразработчиков. Данная проблема заключается в том, что при внесенииизменений в одну из частей проекта необходимо оповещать всех разработчиков,которые использовали или могли использовать эту часть в своей работе.Когда система состоит из большого количества взаимосвязанных подсистем,то синхронизация внутренней документации становится важной самостоятельнойзадачей.Причем синхронизация документации на каждую часть системы — это не болеечем процесс оповещения групп разработчиков. Самим же разработчикам необходимоознакомиться с изменениями и оценить, не сказались ли эти измененияна уже полученных результатах. Все это может потребовать проведения повторноготестирования и даже внесения изменений в уже готовые части проекта.Причем эти изменения, в свою очередь, должны быть отражены во внутреннейдокументации и быть разосланы другим группам разработчиков. Как следствие,объем документации по мере разработки проекта растет очень быстро, так чтотребуется все больше времени для составления документации и ознакомленияс ней.Следует также отметить, что, кроме изучения нового материала, не отпадает и необходимостьв изучении старой информации. Это связано с тем, что вполне вероятнаситуация, когда в процессе выполнения разработки изменяется состав группыразработчиков (этот процесс носит название ротации кадров). Новым разработчикамнеобходима информация о том, что было сделано до них. Причем чемсложнее проект, тем больше времени требуется, чтобы ввести нового разработчикав курс дела. Сложность управления проектом при использовании каскадной схемы в основномобусловлена строгой последовательностью стадий разработки и наличием сложныхвзаимосвязей между различными частями проекта.Последовательность разработки проекта приводит к тому, что одни группы разработчиковдолжны ожидать результатов работы других команд. Поэтому требуетсяадминистративное вмешательство для того, чтобы согласовать сроки работы и составпередаваемой документации.В случае же обнаружения ошибок в выполненной работе необходим возврат к предыдущимэтапам выполнения проекта. Это приводит к дополнительным сложностямв управлении проектом. Разработчики, допустившие просчет или ошибку,вынуждены прервать текущую работу (над новым проектом) и заняться исправлениемошибок. Следствием этого обычно является срыв сроков выполнения какисправляемого, так и нового проектов. Требовать же от команды разработчиковожидания окончания следующей стадии разработки нерационально, так как приводитк существенным потерям рабочего времени.Упростить взаимодействие между группами разработчиков и уменьшить информационнуюперенасыщенность документации можно, уменьшая количество связеймежду отдельными частями проекта. Однако это обычно весьма непросто. Далеконе каждую информационную систему можно разделить на несколько слабосвязанных подсистем.Высокий уровень риска. Чем сложнее проект, тем больше продолжительность каждогоиз этапов разработки и тем сложнее взаимосвязи между отдельными частямипроекта, количество которых также увеличивается. Причем результаты разработкиможно реально увидеть и оценить лишь на этапе тестирования, то есть послезавершения анализа, проектирования и разработки — этапов, выполнение которыхтребует значительного времени и средств. Как уже было отмечено выше, запоздалаяоценка создает значительные проблемы при выявлении ошибок анализаи проектирования — требуется возврат проекта на предыдущие стадии и повторениепроцесса разработки.Однако возврат на предыдущие стадии может быть связан не только с ошибками,но и с изменениями, произошедшими за время выполнения разработки в предметнойобласти или в требованиях заказчика. Причем возврат проекта вследствие этихпричин на доработку не гарантирует, что предметная область снова не изменитсяк тому моменту, когда будет готова следующая версия проекта. Фактически этоозначает, что существует вероятность того, что процесс разработки «зациклится»и никогда не дойдет до сдачи в эксплуатацию. Расходы на проект будут постояннорасти, а сроки сдачи готового продукта — постоянно откладываться.Поэтому можно утверждать, что сложные проекты, разрабатываемые по каскаднойсхеме, имеют повышенный уровень риска.
Достарыңызбен бөлісу: |
