В представленной на рис. 17 модели описываются операционные маршруты, возникающие в связи с обработкой одного требования в ходе эксплуатации программной системы. Для упрощения предполагается, что операционные маршруты не зависят от накапливаемой информации. Это заведомо огрубляющее предположение в том смысле, что принятие решений о требовании фактически делается не только на основании первичных установок, но и с использованием знаний о системе, пользователях, о текущем представлении о приоритетах и предпочтениях. Можно считать, что подобные сведения используются в точках разветвления операционных маршрутов, но то, как осуществляется такое использование, моделью не описывается.
Рис. 17. Модель обработки требований в период эксплуатации системы
Аналогично тому, как это было при организации мини-цикла для трассировки требований, в модели периода эксплуатации началом обработки является поступление сообщения о ходе эксплуатации системы, которое можно трактовать как содержащее требования (контрольная точка ( a )). Это событие может возникать в любой момент периода сопровождения, т. е. обсуждаемая модель является естественным продолжением модели с обработкой требования в мини-цикле (см. п. 3.3). Так как отобразить весь поток сообщений невозможно, рассматривается операционный маршрут только одного сообщения, при этом постулируется, что все сообщения обрабатываются следующим образом:
Поступление сообщения (контрольная точка (a)).
первичный анализ , в ходе которого из сообщения извлекаются требования. Этот период должен быть максимально кратким, ибо пользователю необходимо знать о реакции разработчиков на его сообщение. Результатом первичного анализа является принятие решения о требовании (контрольная точка ( b ), в которой происходит расщепление линии жизненного цикла). Возможны следующие не взаимоисключающие друг друга варианты такого решения:
немедленная реакция — действия, направленные на быстрое уст-ранение замечания, если это возможно, либо указание пользова-телю сроков, когда и как будут учтены поступившие претензии, либо указание пути преодоления трудностей (возможно, времен-ные). Немедленная реакция выполняется всегда, в том числе со-вместно с другими решениями;
требование отклоняется — действия, указывающие пользователю причины отклонения требований и пути преодоления трудностей;
реализация требования в текущей версии — если претензии обоснованы, а устранение замечаний, ошибок и т. п. возможно в рамках обслуживаемой версии, то организуется мини-цикл обработки требований в итерации;
реализация требования в одной из следующих версий — если устранение замечаний в рамках обслуживаемой версии невозможно или нецелесообразно, то требование передается для исполнения на одной из следующих итераций проекта;
реализация требования в другом проекте — если выясняется, что в данном проекте требование реализовать невозможно или нецелесообразно, то, быть может, оно станет одним из аргументов в пользу организации нового проекта.
Мини-цикл обработки требования начинается с анализа, цели которо-го обычны для объектно-ориентированного развития проектов. В част-ности, определяется осуществимость реализации на данной итерации или целесообразность переноса ее на другую итерацию, образуется группа требований, которые должны быть реализованы совместно. Выработка этих решений о стратегии реализации требований приуро-чивается к контрольной точке (c). Особенностью анализа в данном случае является то, что он проводится, как возобновленный процесс, так как основные работы итерации уже выполнены.
р еализация отобранных требований на данной итерации осуществляется по обычной схеме, включающей конструирование и программирование и оценку. В качестве специфики следует указать на особую роль проверочных работ — дополнительный этап проверки реализации , который вкладывается в этап оценки. Эти работы обязательно должны включать повторение проверки того, что было отлажено ранее. Таким образом, пополнение базового окружения проекта приобретает дополнительное содержание: накопление тестовой базы проекта.
р аспространение изменений (контрольная точка 10) — деятельность, направленная на то, чтобы сделанные исправления стали доступны для всех пользователей обслуживаемой версии. При массовом использовании программного изделия эта работа может потребовать значительных ресурсов.
Фаза завершения итерации включает этап окончания работ, содержание которого сводится к сворачиванию деятельности с данной версией программного изделия. Предварительное оповещение о наступлении этапа (контрольная точка 11) важно для пользователей, чтобы они смогли либо перестроиться, либо найти аргументы (в частности, ресурсы) в пользу продолжения сопровождения изделия. Как показывает практика, чтобы не потерять своих пользователей, очень часто приходится продолжать поддерживать весьма старые разработки, вкладывая в это солидные средства.
Заключение
Обсуждение жизненного цикла представлено в настоящей работе как последовательное развитие и уточнение понятий под влиянием потребностей развивающихся методов и технологий программирования. Однако из этого не должно складываться впечатление, что столь же прямолинейна историческая линия развития представления о том, какие этапы и как проходятся в течение жизни программы. Напротив, начиная с семидесятых годов XX столетия, когда сформировалась потребность в изучении жизненных циклов, и до наших дней варианты их моделей все множатся и множатся. Причина тому — особенности проектов, требующие учета и организационно-технологической поддержки. В качестве иллюстрации этого тезиса далее упоминаются лишь некоторые особенности, которые нашли свое отражение в реальных моделях жизненного цикла:
совместная разработка программного обеспечения и оборудования (общего или специального) назначения,
разработка программного обеспечения для встроенных систем,
разработка программного обеспечения по уже существующему прототипу,
разработка, включающая быстрое предварительное построение прототипа,
построение сетевых комплексов,
решение задач переиспользования программного обеспечения,
учет требований повышенной надежности разрабатываемых программно-аппаратных систем,
разработка адаптивных систем,
разработка систем с настраиваемым интерфейсом,
конструирование программных инструментов,
использование технологических сред для разработки программных систем (различные варианты моделей).
Этот список может быть продолжен. Так, обнаруживаются и отражаются в моделях особенности жизненного цикла долго и быстро живущих программ, длительных, средних и коротких проектов. Как показывает анализ моделей, предлагаемых для разных ситуаций, они лишь уточняют и дополняют общие положения, отслеживанию которых было уделено внимание в предыдущих разделах.
Среди всех мотивов моделирования жизненного цикла особое место занимает систематизация работ, выполняемых при разработке программного обеспечения. Систематизация — первый шаг на пути автоматизации любого производства, и в частности, производства программ. Следующие шаги — определение технологических маршрутов деятельности работников данного производства, выявление узких мест, доступных для автоматизации, и разработка инструментов для них. Далее процесс развивается вширь и вглубь: охватываются автоматизацией другие части технологических маршрутов, совершенствуются ранее построенные инструменты, формируются методы их эффективного применения. Последнее означает формирование новых технологий, и, как следствие, появляется потребность автоматизации новых видов деятельности, обусловленных данными технологиями. Наконец, наступает момент, когда совокупность потребностей в автоматизации разного рода деятельности, связанных, хотя и не обязательно напрямую, с первоначальной систематизацией, формирует качественно иную потребность в комплексной автоматизации. Это время появления стандартов и стандартных решений, интеграции сложившихся технологий и доработка того, что не вписывается в интегральную схему.
В предыдущем абзаце представлен эскиз формирования произвольного автоматизированного технологичного производства. Не является исключением и процесс технологизации производства программного обеспечения. Есть, конечно, специфика, но она не столь значительна, чтобы считать данное производство чем-то исключительным.
Первая стадия автоматизации программирования связана с поддержкой этапа программирования жизненного цикла. Здесь проявляется и специфика: систематизация работ по производству программного обеспечения осуществлялась после осознания того, что поддержка кодирования, хотя и способствует росту производительности труда, но не является достаточным для промышленного конструирования программ. Появление на этой стадии систем программирования и всевозможных средств помощи в наборе текстов предшествовало периоду, когда начинали внедряться разного рода отладочные средства. Именно в это время (т. е. лишь к концу шестидесятых годов) в ответ на потребность в разработке больших и сложных программ было осознано понятие жизненного цикла.
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 |
