Инсталляция системы

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

Ввод системы в эксплуатацию

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

Эволюция систем

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

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

Вывод систем из эксплуатации

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

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

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

Приобретение систем

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

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

1 Для покупки или заключения контракта на разработку и построение системы необ­ходима полностью законченная системная спецификация.

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

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

Модели процесса создания ПО

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

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

Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО (такие, как разработка спецификации, проектирование и производство, аттестация и модернизация ПО), представляются как отдельные этапы этого процесса.

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

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

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

Каскадная модель

Это первая модель процесса создания ПО, порожденная моделями других инженерных процессов [300]. Она показана на рис. 3.1. Эту модель также иногда называют моделью жиз­ненного цикла программного обеспечения. Основные принципиальные этапы (стадии) этой модели отражают все базовые виды деятельности, необходимые для создания ПО.

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

Проектирование системы и программного обеспечения. Процесс проектирования системы разбивает системные требования на требования, предъявляемые к аппаратным средствам, и требования к программному обеспечению системы. Разрабатывается общая архитектура системы. Проектирование ПО предполагает определение и описание основных программных компонентов и их взаимосвязей.

Кодирование и тестирование программных модулей. На этой стадии архитектура ПО реализуется в виде множества программ или программных модулей. Тестирование каждого модуля включает проверку его соответствия требованиям к данному модулю.

Сборка и тестирование системы. Отдельные программы и программные модули интегрируются и тестируются в виде целостной системы. Проверяется, соответствует ли система своей спецификации.

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

Рис. 3.1. Жизненный цикл программного обеспечения

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

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

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

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

Эволюционная модель разработки

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

Формальная разработка систем

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

Разработка ПО на основе ранее созданных компонентов

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

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

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

Рис. 3.5. Разработка ПО с повторным использованием ранее созданных компонентов

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

Итерационные модели разработки ПО

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

В этом разделе я представлю две гибридные итерационные модели, сочетающие не­сколько различных подходов к разработке ПО и разработанные специально для поддерж­ки итерационного способа создания ПО.

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

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

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

Модель пошаговой разработки

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

Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель (рис. 3.6) была предложена Миллсом (Mills, [240]) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увели­чить для заказчика временной период окончательного принятия решения обо всех дета­лях системных требований.

Незавершенная система Рис. 3.6. Модель пошаговой разработки

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

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

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

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

Процесс пошаговой разработки имеет целый ряд достоинств.

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

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

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

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

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

В настоящее время предложен метод так называемого экстремального программиро­вания (extreme programming), который устраняет некоторые недостатки метода пошаго­вой разработки. Этот метод основан на пошаговой разработке малых программных ком­понентов, реализующих небольшие функциональные требования, постоянном вовлече­нии заказчика в процесс разработки и обезличенном программировании (см. главу 23). В статье [31] описан метод экстремального программирования и приведено несколько от­четов о его успешном применении, однако подобные отчеты можно привести для всех ос­новных методов разработки ПО.

Спиральная модель разработки

Спиральная модель процесса создания программного обеспечения (рис. 3.7) была впервые предложена в статье [47] и в настоящее время получила широкую известность и популярность. В отличие от рассмотренных ранее моделей, где процесс создания ПО представлен в виде последовательности отдельных процессов с возможной обратной свя­зью между ними, здесь процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии (итерации) процесса создания ПО. Так, самый внут­ренний виток спирали соответствует стадии принятия решения о создании ПО, на сле­дующем витке определяются системные требования, далее следует стадия (виток спирали) проектирования системы и т.д.

Каждый виток спирали разбит на четыре сектора.

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

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

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

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

Спецификация программного обеспечения

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

Рис. 3.8. Процесс разработки требований

Схема процесса разработки требований показана на рис. 3.8. Результатом его вы­полнения является разработка документации, формализующей требования, предъяв­ляемые к системе, т.е. создание системной спецификации. В этой документации тре­бования обычно представлены на двух уровнях детализации. На самом верхнем уров­не представлены требования, определяемые конечными пользователями или заказчи­ками ПО; но для разработчиков необходима более детализированная системная спе­цификация.

Проектирование и реализация ПО

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

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

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

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

Ниже перечислены отдельные этапы процесса проектирования.

Архитектурное проектирование. Определяются и документируются подсистемы и взаимосвязи между ними.

Обобщенная спецификация. Для каждой подсистемы разрабатывается обобщенная спецификация на ее сервисы и ограничения.

Проектирование интерфейсов. Для каждой подсистемы определяется и документируется ее интерфейс. Спецификации на эти интерфейсы должны быть точно

выраженными и однозначными, чтобы использование подсистем не требовало

знаний о том, как они реализуют свои функции. На этом этапе можно применить методы формальных спецификаций, рассмотренные в главе 9.

Рис. 3.9. Обобщенная схема процесса проектирования

Компонентное проектирование. Проводится распределение системных функций (сервисов) по различным компонентам и их интерфейсам.

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

Проектирование алгоритмов. Детально разрабатываются алгоритмы, предназначенные для реализации системных сервисов.

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

Методы проектирования

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

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

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

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

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

Модель "сущность-связь", которая применяется для описания сущностей (объектов программной системы) и связей между ними. Эта модель часто используется при проектировании структур баз данных.

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

4. Объектно-ориентированные методы, с помощью которых получают иерархическую модель системы, модели статических и динамических отношений между объектами и модель взаимодействия объектов во время работы системы.

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

Литература:

4. Ларман, Крэг. Применение UML и шаблонов проектирования.: Пер. с англ..: Уч. Пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил. – Парал. Тит. Англ..

5. Соммервилл, Иан. Инженерия програмного обеспечения, 6-е издание.: Пер. с англ.. – М.: Издательский дом «Вильямс» 2002. – 624 с.: ил. – Парал. Тит. Анг.

6. Ф.Брукс. Мифический человеко-месяц или как создаются программные системы. – пер. с англ. – СПб.: Символ-Плюс, 2001.-304 с.: ил.

Лекция 3.

Проблема управления проектами. Формирование и спецификация пользовательских требований

План

Процессы управления

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

План проекта

Контрольные отметки этапов работ

График работ

Временные и сетевые диаграммы

Управление рисками

Определение рисков

Анализ рисков

Планирование рисков

Мониторинг рисков

Требования к программному обеспечению

Виды требований: пользовательские требования, системные требования, проектная системная спецификация

Функциональные и нефункциональные требования

Требования предметной области

Процессы управления

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

• Написание предложений по созданию ПО.

• планирование и составление графика работ по созданию ПО.

• Оценивание стоимости проекта.

• Контроль за ходом выполнения работ.

• Подбор персонала.

• Написание отчетов и представлений

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

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

Таблица 4.1. Виды планов

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

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

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

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

План проекта

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

План, структуру которого я представлю ниже, принадлежит именно к последнему типу планов. Детализация планов проектов очень разнится в зависимости от типа разрабаты­ваемого программного продукта и организации-разработчика. Но в любом случае боль­шинство планов содержат следующие:

1. Введение. Краткое описание целей проекта и проектных ограничений (бюджетных, и т.д.), которые важны для управления проектом.

2. Организация выполнения проекта. Описание способа подбора команды разработчиков и распределение обязанностей между членами команды.

3. Анализ рисков. Описание возможных проектных рисков, вероятности их проявле­ния и стратегий, направленных на их уменьшение.

4. Аппаратные и программные ресурсы, необходимые для реализации проекта. Перечень ап­паратных средств и программного обеспечения, необходимого программного продукта. Если аппаратные средства требуется закупать, их стоимость совместно с графиком закупки и поставки.

5. Разбиение работ на этапы. Процесс реализации проекта разбивается на процессы, определяются этапы выполнения проекта, приводится описание результатов ("выходов") каждого этапа и контрольные отметки. График работ. В этом графике отображаются зависимости между отдельными процессами (этапами) разработки ПО, оценки времени их выполнения и распределение членов команды разработчиков по отдельным этапам.

6. Механизмы мониторинга и контроля за ходом выполнения проекта. Описываются предоставляемые менеджером отчеты о ходе выполнения работ, сроки их предоставления, а также механизмы мониторинга всего проекта.

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

Контрольные отметки этапов работ

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

При планировании процесса определяются контрольные отметки— вехи, окончание определенного этапа работ. Для каждой контрольной отметки создается отчет, который предоставляется руководству проекта. Эти отчеты не должны быть большими объемными документами; они должны подводить краткие итоги окончания отдельного логически завершенного этапа проекта. Этапом не может быть, например, "Написание 80% кода программ", поскольку невозможно проверить завершение такого "этапа"; кроме того, подобная информация практически бесполезна для управления, поскольку здесь не отображается связь этого "этапа" с другими этапами создания ПО.

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

График работ

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

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

В процессе составления графика весь массив работ, необходимых для реализации проекта, разбивается на отдельные этапы и оценивается время, требующееся для каждого этапа. Обычно многие этапы выполняются параллельно. График ра­бот должен предусматривать это и распределять производственные ресурсы между ними наиболее оптимальным образом. Нехватка ресурсов для выполнения какого-либо крити­ческого этапа — частая причина задержки выполнения всего проекта.

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

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

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

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

График работ по проекту обычно представляется в виде набора диаграмм и графиков, показывающих разбиение проектных работ на этапы, зависимости между этапами и распределение разработчиков по этапам. Эти диаграммы рассматриваются в следующем разделе. Отмечу, что в настоящее время существует много различных программных средств поддержки управления проектами, например Microsoft Project.

Временные и сетевые диаграммы

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

Минимальное время выполнения всего проекта можно рассчитать, просуммировав в сете­вой диаграмме длительности этапов на самом длинном пути¹ от начала проекта до его оконча­ния (это так называемый критический путь). В нашем случае продолжительность проекта со­ставляет 11 недель или 55 рабочих дней. Таким образом, общая продолжительность реализации проекта зависит от этапов работ, находящихся на критическом пути. Любая задержка в завершении лю­бого этапа на критическом пути приведет к задержке всего проекта.

Рис. 4.4. Временная диаграмма длительности этапов

Задержка в завершении этапов, не входящих в критический путь, не влияет на продолжительность всего проекта до тех пор, пока суммарная длительность этих этапов (с учетом задержек) на каком-нибудь пути не превысит продолжительности работ на крити­ческом пути. Например, задержка этапа Т8 на срок, меньший 20 дней, никак не влияет на общую продолжительность проекта. На рис. 4.4 представлена временная диаграмма, на которой показаны возможные задержки на каждом этапе.

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

На рис. 4.4 показано другое представление графика работ. Это временная диаграмма (иногда называемая по имени ее изобретателя диаграммой Гантта) может быть построена программными средствами поддержки процесса управления. Она показывает длитель­ность выполнения каждого этапа и возможные их задержки (показаны затененными пря­моугольниками), а также даты начала и окончания каждого этапа. Этапы критического пу­ти не имеют затененных прямоугольников; это означает, что задержка с завершением данных этапов приведет к увеличению длительности всего проекта.

Подобно распределению времени выполнения этапов, менеджер должен рассчитать распределение ресурсов по этапам, в частности назначить исполнителей на каждый этап. В табл. 4.3 приведено распределение разработчиков на каждый этап, представленный на рис. 4.4.

Таблица 4.3. Распределение исполнителей по этапам

Этап	Исполнитель
ТІ	Джейн
T2	Анна
Т3	Джейн
Т4	Фред
Т5	Мэри
Т6	Анна
Т7	Джим
Т8	Фред
Т9	Джейн
Т10	Анна
ТІЇ	Фред
Т12	Фред

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

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

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

Управление рисками

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

1. Риски для проекта, которые влияют на график работ или ресурсы, необходимые для выполнения проекта.

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

3. Бизнес-риски, относящиеся к организации-разработчику или поставщикам.

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

Таблица 4.4. Возможные риски программных проектов

Риск	Тип риска	Описание риска
Текучесть разработчиков	Риск для проекта	Опытные разработчики покидают проект до его завершения
Изменение в управлении организацией	Риск для проекта	Организация меняет свои приоритеты в управлении проектом
Неготовность аппаратных средств	Риск для проекта	Аппаратные средства, которые необходимы для проекта, не поступили вовремя или не готовы к эксплуатации
Изменение требований	Риск для проекта и для разрабатываемого продукта	Появление большого количества непредвиденных изменений в требованиях, предъявляемых к разрабатываемому ПО
Задержка в разработке спецификации	Риск для проекта и для разрабатываемого продукта	Спецификации основных интерфейсов подсистем не поступили к разработчикам в соответствии с графиком работ
Недооценка размера раз­рабатываемой системы	Риск для проекта и для разрабатываемого продукта	Размер системы значительно превысил первоначальную оценку
Недостаточная эффективность CASE-средств	Риск для проекта и для разрабатываемого продукта	CASE-средства, предназначенные для поддержки проекта, оказались менее эффективными, чем ожидалось
Изменения в технологии разработки ПО	Риск для разрабатываемого продукта	Основные технологии построения программной системы заменяются новыми
Появление конкурирую­щего программного про­дукта	Бизнес-риск	На рынке программных продуктов до окончания проекта появилась конкурирующая программная систем

Схема процесса управления рисками показана состоит из четырех стадий.

Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта и бизнес риски.

Анализ рисков. Оценивается вероятность и последовательность появления рисковых

ситуаций.

Планирование рисков. Планируются мероприятия по предотвращению рисков или минимизации их воздействия на проект.

Мониторинг рисков. Постоянное оценивание вероятностей рисков и выполнение мероприятий по смягчению последствий проявления рисковой ситуаций.

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

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

Определение рисков

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

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

1. Технологические риски. Проистекают из программных и аппаратных технологий, на основе которых разрабатывается система.

2. Риски, связанные с персоналом. Связаны с членами команды разработчиков.

3. Организационные риски. Проистекают из организационного окружения, в котором выполняется проект.

4. Инструментальные риски. Связаны с используемыми CASE-средствами и другими средствами поддержки процесса создания ПО.

5. Риски, связанные с системными требованиями. Проявляются при изменении требований, предъявляемых к разрабатываемой системе.

6. Риски оценивания. Связанные оцениванием характеристик программной системы и ресурсов, необходимых для реализации проекта.

Анализ рисков

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

Вероятность риска считается очень низкой, если она имеет значение менее 10%; низкой, если ее значение от 10 до 25 %; средней при значениях от 25 до 50%; высокой, если значение колеблется от 50 до 75%; очень высокой при значениях более 75%.

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

Результаты анализа рисков должны быть представлены в виде таблицы рисков, упоря­доченных по степени возможного ущерба. В табл. 4.6 приведен упорядоченный список рисков, описанных в табл4.5; там же указаны вероятности этих рисков. Здесь вероятности рисков и степень ущерба от них указаны произвольно. На практике для их определения необходима подробная информация о проекте, технологии создания ПО, команде разра­ботчиков и о самой организации.

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

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

В статье [47] рекомендуется определить и отслеживать "10 верхних" рисков, но я ду­маю, что это необоснованная рекомендация. Количество рисков, которые необходимо отслеживать, зависит от конкретного проекта. Это может быть пять рисков, а может — пятнадцать. Но, конечно, количество рисков, по которым проводится мониторинг, должно быть обозримым. Большое количество отслеживаемых рисков потребует огромного количества собираемой информации. Из списка рисков, представленных в табл. 4.6, для мониторинга следует отобрать все восемь рисков, которые могут привести к катастрофическим и серьезным последствиям.

Планирование рисков

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

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

Минимизационнш стратегии. Направлены на уменьшение возможного ущерба от рисков. Примером служит стратегия уменьшения ущерба от болезни членов коман­ды разработчиков (см. табл. 4.7).

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

Мониторинг рисков

Мониторинг рисков заключается в регулярном пересчете вероятностей рисков и ущерба, который они могут нанести. Для этого необходимо постоянно отслеживать факторы, которые влияют на вероятность рисков и возможный ущерб. Эти факторы зависят от типов риска. В табл. 4.8 приведены признаки, которые помогают определить тип риска.

Таблица 4.8. Признаки рисков

Тип риска	Признаки
Технологические риски	Задержки в поставке оборудования или программных средств поддержки процесса создания ПО, многочисленные документи­рованные технологические проблемы
Риски, связанные с персоналом	Низкое моральное состояние персонала, натянутые отношения между членами команды разработчиков, низкое качество выпол­ненной работы
Организационные риски	Разговоры среди персонала о пассивности и недостаточной ком­петентности высшего руководства организации
Инструментальные риски	Нежелание разработчиков использовать программные средства поддержки, неодобрительные отзывы о CASE-средствах, запросы на более мощные инструментальные средства
Риски, связанные с системными требова­ниями	Необходимость пересмотра многих системных требований, не­довольство заказчика ПО
Риски оценивания	Изменения графика работ, многочисленные отчеты о нарушении графика работ

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

Требования к программному обеспечению

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

Термин требования (к программной системе) может трактоваться по-разному. В некоторых случаях под требованиями понимаются высокоуровневые обобщенные утверждения о функциональных возможностях и ограничениях системы. Другая крайняя ситуация — детализированное математическое формальное описание системных функций. Дэвис (Davis) так объясняет причины этих различий.

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

Виды требований: пользовательские требования, системные требования, проектная системная спецификация

Некоторые проблемы, возникающие в процессе разработки требований, порождены отсутствием четкого понимания различия между этими разными уровнями требований. Чтобы различить требования разных уровней, здесь используются термины пользовательские требования (user requirements) для обозначения высокоуровневых обобщенных требо­ваний и системные требования (system requirements) для детализированного описания вы­полняемых системой функций. Кроме требований этих двух уровней, применяется еще более детализированное описание системы — проектная системная спецификация (software design specification), которая может служить мостом между этапом разработки требований и этапом проектирования системы. Три перечисленных вида требований можно опреде­лить следующим образом.

Функциональные и нефункциональные требования

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

1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные вход­ные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых слу­чаях указывается, что система не должна делать.

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

3. Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

Литература:

1. Ларман, Крэг. Применение UML и шаблонов проектирования.: Пер. с англ..: Уч. Пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил. – Парал. Тит. Англ..

2. Соммервилл, Иан. Инженерия програмного обеспечения, 6-е издание.: Пер. с англ.. – М.: Издательский дом «Вильямс» 2002. – 624 с.: ил. – Парал. Тит. Анг.

3. Ф.Брукс. Мифический человеко-месяц или как создаются программные системы. – пер. с англ. – СПб.: Символ-Плюс, 2001.-304 с.: ил.

Лекция № 4. Формирование и спецификация системных требований. Методы формирования системных требований. Аттестация системных требований

План

Системные требования

Структурированный язык спецификаций

Создание спецификаций с помощью PDL

Спецификация интерфейсов

Документирование системных требований

Разработка требований

Анализ осуществимости

Формирование и анализ требований

Опорные точки зрения

Сценарии

Сценарии событий

Аттестация требований

Обзор требований

Управление требованиями

Постоянные и изменяемые требования

Планирование управления требованиями

Управление изменениями требований

Этнографический подход

Системные требования

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

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

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

2. В большинстве случаев разрабатываемая система должна взаимодействовать с уже существующими системами. Это накладывает определенные ограничения на архи­тектуру новой системы.

3. В качестве внешнего системного требования может выступать условие использова­ния для разрабатываемой системы специальной архитектуры (см. главу 18).

Структурированный язык спецификаций

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

Пример использования структурированного языка для описания системных требова­ний приведен в работе. Здесь для написания спецификации требований для про­граммной системы управления полетами разработаны специальные формы, помогающие описать входные и выходные данные и функции системы.

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

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

1. Описание функции или объекта.

2. Описание входных данных и их источники.

3. Описание выходных данных с указанием пункта их назначения.

4. Указание, что необходимо для выполнения функции.

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

6. Описание побочных эффектов (если они есть).

Создание спецификаций с помощью PDL

Для уменьшения присущей естественному языку нечеткости понятий при описании системных требований используется специальный язык описания программ (program description language — PDL). Этот язык подобен таким языкам программирования, кaк Java и Ada, но более абстрактен. Достоинством применения PDL для создания спецификации является то, что в такой спецификации можно проверить синтаксис и семантику сущест­вующими программными средствами. Эти проверки позволяют удалить ошибки и несо­гласованность в описании требований.

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

1. Если описываемая операция состоит из последовательности простых действий и важен порядок их выполнения. Описать такие последовательности действий на ес­тественном языке порой затруднительно, поскольку их выполнение может сопро­вождаться вложенными условиями или они могут повторяться циклически. Этой ситуации соответствует спецификация системы обслуживания банкоматов, приве­денная в листинге 5.1. Здесь в качестве PDL я использовал язык Java. В этом листин­ге я привел только часть спецификации, опустив описания некоторых сервисов. Полную спецификацию можно найти на Web-странице данной книги.

2. Если необходимо специфицировать аппаратные или программные интерфейсы, так как практически во всех спецификациях системных требований приходится описывать интерфейсы.

Вместе с тем подход к построению спецификаций, основанный на PDL, имеет свои не­достатки.

1. PDL, используемый для написания спецификации, может не иметь достаточных средств для описания всех системных функций.

2. Спецификации, созданные с помощью PDL, понятны только людям, имеющим оп­ределенные знания языков программирования.

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

Наиболее эффективным способом разработки спецификаций является сочетание под­хода, основанного на PDL, с использованием структурированного естественного языка. В этом случае формализованные записи на естественном языке используются для описа­ния системы в целом, a PDL — для описания последовательностей управляющих действий или для детализированного описания интерфейсов.

Спецификация интерфейсов

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

Различают три типа специфицируемых интерфейсов.

1. Процедурные интерфейсы, когда существующие подсистемы предлагают набор сервисов, доступных посредством вызываемой интерфейсной процедуры.

2. Структуры (интерфейсные форматы) данных, которые пересылаются от одной подсистемы к другой. В этом случае может использоваться PDL, основанный на языке программирования Java, который позволяет описать классы данных с соот­ветствующими полями, формирующими структуру данных. Однако, я полагаю, для описания этого типа интерфейса наиболее подходят диаграммы "сущность-связь", описанные в главе 7.

3. Специальные представления данных, например в виде упорядоченной последова­тельности двоичных разрядов. Язык Java не поддерживает такие детальные описа­ния данных, поэтому я не рекомендую в подобном случае использовать PDL, осно­ванный на языке Java.

Документирование системных требований

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

Системную спецификацию читает множество разных людей, начиная от высшего ру­ководства компании — заказчика системы и заканчивая рядовым разработчиком системы. На рис. 5.3, взятом из статьи [204], показаны категории читателей спецификации.

Рис 6.3. Читатели системной спецификации

Хенингер (Heninger) сформулировал шесть условий, которым должна соответ­ствовать спецификация программной системы.

• Описывать только внешнее поведение системы.

• Указывать ограничения, накладываемые на процесс реализации системы.

• Предусматривать возможность внесения изменений в спецификацию.

• Служить справочным средством в процессе сопровождения системы.

• Отображать весь жизненный цикл системы.

• Предусматривать реакцию системы и группы сопровождения на непредвиденные (нештатные) ситуации.

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

Многие организации, такие, как Министерство обороны США и Институт инженеров по электротехнике и радиоэлектронике IEEE, разработали собственные стандарты доку­ментирования спецификаций. В монографии [89] описаны некоторые из этих стандартов, а также проведено их сравнение. Наиболее известный стандарт разработан IEEE и назы­вается IEEE/ANSI 830-1993 [IEEE, 1993]. В книге [334], содержащей великолепный обзор работ по технологии разработки требований, приведено полное описание этого стандар­та. Данный стандарт предполагает следующую структуру спецификации.