Губанов Юрий Александрович, mail Критерии зачёта min 50% посещаемость доклад

Вид материалаДоклад
Проектирование систем
Специфицирование функциональных характеристик подсистем
Специфицирование интерфейсов подсистем
Разработка подсистем
Сборка системы
Инсталляция системы
Реальное окружение не совпадает с тем, для которого система проектировалась
Человеческий фактор
Сосуществование со старой системой
Физические проблемы
Ввод системы в эксплуатацию
Эволюция систем
Подобный материал:
1   2   3   4   5   6   7   8   9   ...   20

Проектирование систем


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


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

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

Разработка подсистем


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

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

Сборка системы


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

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

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


При инсталляции система "погружается" в то окружение, в котором она должна работать. В процессе инсталляции сложных систем могут возникнуть нетривиальные проблемы, в частности:
  • Реальное окружение не совпадает с тем, для которого система проектировалась. Проблема, известная по аналогичным проблемам с инсталляцией ПО (отсутствующие системные функции, другое ПО и т.п.).
  • Человеческий фактор. Потенциальные пользователи могут относиться враждебно к внедрению системы (по причинам, описанным выше в "Окружении системы"), что может повлечь за собой действия от отказа в предоставлении информации для инсталляции до саботажа.
  • Сосуществование со старой системой. Новая и старая системы могут сосуществовать до тех пор, пока в организации не убедятся, что новая система работает, как требуется. Это может привести к различным конфликтам (например, для ПО - использование различных версий общих/системных библиотек).
  • Физические проблемы. Экзотично звучит, но система может попросту "не влезть" в здание, где планируется ее инсталлировать (недостаточное количество или размеры помещений, вентиляции, каналов для кабелей и т.п.)

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


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

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

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


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

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

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