Процессы проектирования. Проектирование программной архитектуры

(имелось ввиду что в ieee 1471, захмане, togaf’е есть чем моделировать ПА?)


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

(???)

Процессы проектирования. Шаблоны программной архитектуры.

(синглтоны, фабрики, etc.?)


Процессы проектирования. Проектирование инфраструктуры.

Инфраструктура состоит из:

· Техническая составляющая (основное оборудование – железо; дополнительное оборудование – устройства I\O + устройства конечного управления, т.е. сканеры, принтеры, плоттеры, вспомогательное оборудование – коммуникация внутри ИС между компонентами и внешним миром – роутеры и т.д.);

· Программное обеспечение (дополнительные программные продукты, которые обеспечивают функциональность ИС - OS + почты, etc.);

· Математическое обеспечение (протоколы, драйвера, алгоритмы – т.е. несамостоятельный программный продукт);

· Персонал (кто будет обслуживать ИС);

· Лингвистическое обеспечение (описание ИС, её функционал, etc. – комплексность документов).

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

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

Реализация инфраструктуры предшествует эксплуатации, одновременно с тестированием ИС после разработки.

Следует различать инфраструктуру ИС и инфраструктуру проекта по созданию ИС.

Цели и наборы компонентов инфраструктуры проекта по созданию ИС:

· Средства коммуникации между участниками ИС;

· Средства разработки;

· Обеспечивающий персонал (бухгалтеры, уборщицы);

· Лингвистическое обеспечение;

· Единое информационное пространство – СУБД + БД.

Задачи:

· Обеспечить максимальное КПД проекта за счет улучшение взаимодействия участников проекта;

· Минимизация ошибок за счет обеспечения коммуникации.

Зачем использовать:

· Позволяет минимизировать риски неудачного проекта;

· Расчет стоимости проекта.


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: