Матричная организационная структура

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

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

Матричная структура управления

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

Недостатки: наличие двойного подчинения, конфликты из-за двойного подчинения, сложность информационных связей.

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

2.3.2. Предоставить кадровый состав подразделения

Можно предоставить в виде таблицы:

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

Перечислить виды документов и в приложении предоставить образцы или шаблоны.

2.3.4. Блоки НСИ, существующие на предприятии

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

Требование обеспечения взаимодействия и унификации различных прикладных систем автоматизации бизнес-процессов, консолидации отчётности приводит к необходимости построения системы нормативно-справочной информации

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

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

Консолидация всех видов отчётности в сопоставимых обозначениях

- Обеспечение интеграции информационных систем на уровне справочных данных

- Повышение оперативности и эффективности управления организацией

- Повышение доступности и достоверности информации

- Повышение управляемости бизнес-процессов за счёт внедрения единых регламентов ведения НСИ

Пример:

- организационно – административные;

А: ~130 штук положений и регламентов по управлению (системные документы)

- технические;

А: ~700 штук ограничительных стандартов, сведенные в 25 альбомов ограничительных стандартов

- ГОСТы, ОСТы, ТУ;

А:

· ТехНорма ИнтраДок (все ГОСТ)

· NormaCS (ЦКТИ, РД – блок электроэнергетика)

· Консультант Плюс (юридические документы, ПБ, РД)

·

- Другое.

2.3.5. Функциональная модель (бизнес-функции организации «AS-IS»)

Функциональная модель может быть создана с помощью методологии SADT. (Дэвид А. Марка и Клемент МакГоуэн «Методология структурного анализа и проектирования».

Рекомендуется в качестве нормативного документа при построении функциональных диаграмм использовать руководящий документ РД-IDEF0-2000. Методология функционального моделирования IDEF0.

В качестве инструментальной поддержки можно использовать пакет AllFusion Modelling Suite в части AllFusion Process Modeler 7.1 (BPwin) модель IDEF0.

Все элементы модели должны быть описаны. Каждая диаграмма должна сопровождаться текстовым описанием (рекомендуется использовать Model report и Diagram report).

2.3.6. Модель потоков данных (информационные потоки, обеспечивающие БП и бизнес-функции организации «AS-IS»)

Модель потоков данных может быть описана с помощью DFD - диаграмм.

В качестве инструментальной поддержки можно использовать пакет AllFusion Modelling Suite в части AllFusion Process Modeler 7.1 (BPwin), модель DFD.

Все элементы модели должны быть описаны. Каждая диаграмма должна сопровождаться текстовым описанием (рекомендуется использовать Model report и Diagram report).

2.3.7. Система управления и организационная структура («AS-IS»)

Организационная структура (ГОСТ Р ИСО 9000:2008 "Системы менеджмента качества. Основные положения и словарь) - распределение ответственности, полномочий и взаимоотношений между работниками.

Может быть описана произвольным образом, в том числе и с использованием пакета AllFusion Modelling Suite в части AllFusion Process Modeler 7.1 (BPwin), Organization Charts.

Все элементы модели в этом случае должны быть описаны. Каждая диаграмма должна сопровождаться текстовым описанием (рекомендуется использовать Model report и Diagram report).

2.4. Описание информационных ресурсов

-описать характеристики информационных ресурсов объекта

-представить классификацию информационных ресурсов

2.5. Определение уровня зрелости процессов управления организации

Может быть описана по классификации Capability Maturity Model. Пятиуровневая модель.

2.6. Состояние ИТ в организации (степень автоматизации процессов, покрытие функциональных областей, уровень зрелости ИТ-процессов)

Также рекомендуется использовать модели CMM, CMMI, стандарт Cobit 4.3.

2.7. Анализ «узких мест» с точки зрения бизнес-цели организации

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

- анализ функциональной деятельности выбранной предметной области на соответствие лучшей бизнес - практике или эталонной модели (стандарты и модели MRP, ERP, CRM, PDM,…);

- анализ функционального взаимодействия выбранной предметной области с внешними объектами на соответствие лучшей бизнес - практике или эталонной модели (стандарты и модели MRP, ERP, CRM, PDM…);

- анализ внутреннего документооборота выбранной предметной на соответствие лучшей бизнес - практике или эталонной модели (стандарты и модели MRP, ERP, CRM, PDM,…);

- анализ информационных потоков и информационного взаимодействия с внешними объектами на соответствие лучшей бизнес - практике или эталонной модели (стандарты и модели MRP, ERP, CRM, PDM,…);

- анализ информационной инфраструктуры выбранной предметной области и предприятия в целом на соответствие лучшей бизнес - практике или эталонной модели (стандарты и модели MRP, ERP, CRM, PDM,…).

2.8. Формулирование общих требований к решению рассматриваемой задачи и критериев оценки результативности решения

-сформулировать общие требования к решению рассматриваемой задачи и критерии оценки результативности решения

-общие требования к решению задачи должны подразделяться на функциональные и нефункциональные

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

-критерии результативности должны отражать необходимый уровень достижения требований.

2.9. Описание контекста решения задачи в рамках подсистемы

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

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

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

Глава 3. РАЗРАБОТКА ПРОЕКТНЫХ РЕШЕНИЙ ПО УПРАВЛЕНИЮ ОБЪЕКТОМ УПРАВЛЕНИЯ

Раздел должен отражать результат дипломного проектирования, а не процесс проектирования.

3.1. Постановка задачи

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

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

Постановка задачи должна включать следующие обязательные составляющие.

-цель задачи и детализацию цели на частные подцели.

-перечень и характеристика входной информации.

-перечень и характеристика промежуточной и нормативной информации.

-перечень и характеристика выходной информации

-контекстная диаграмма

-периодичность решения задачи, условия реализации.

-диаграммы вариантов использования

3.1.1. Возможности бизнеса и нужды клиента

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

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

3.1.2. Бизнес – цели и критерии успеха

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

Примеры:

Финансовые цели:

- Освоить Х% рынка за Y месяцев;

- Увеличить сектор рынка в стране X на Y% за Z месяцев;

- Достигнуть объема продаж X единиц или дохода, равного $Y, за Z месяцев;

- Получить Х% прибыли или дохода по инвестициям в течение Y месяцев;

- Достигнуть положительного баланса по этому продукту в течение Y месяцев;

- Сэкономить $Х в год, которые в настоящий момент расходуются на обслуживание системы;

- Уменьшить затраты на поддержку на Х% за Z месяцев;

- Получить не более X звонков в службу обслуживания по каждой единице товара и Y звонков по гарантии каждой единицы товара в течение Z месяцев после выпуска товара;

- Увеличить валовую прибыль для существующего бизнеса с Х до Y%.

Нефинансовые цели:

- Достигнуть показателя удовлетворения покупателей, равного по крайней мере X, в течение Y месяцев со времени выпуска товара

- Увеличить производительность обработки транзакций на Х% и снизить уровень ошибок данных до величины не более Y%

- Достигнуть определенного времени для достижения доминирующего положения на рынке

- Разработать надежную платформу для семьи связанных продуктов

- Разработать специальную базовую технологическую основу для организации

- Получить X положительных отзывов в отраслевых журналов к определенной дате

- Добиться признания продукта лучшим по надежности в опубликованных обзорах продуктов к определенной дате

- Соответствовать определенным федеральным и государственным постановлениям

- Уменьшить время обработки до X часов на Y% звонков покупателей в службу поддержки

3.1.3. Потребности клиента или рынка

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

3.1.4. Бизнес – риски

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

3.1.5. Положение об образе проекта

В данном разделе дается сжатое положение об образе проекта, обобщающее долгосрочные цели и назначение новой ИС (нового ИТ – решения).

Для этого может быть использован шаблон, состоящий из следующих ключевых слов (Moore, 1991):

- для (целевая аудитория покупателей);

- который (положение о потребностях или возможностях);

- эта (этот) (имя продукта, новой системы)

- является (категория продукта);

- который(ая) (ключевое преимущество, основная причина для покупки или использования);

- в отличие от (основной конкурирующий продукт, текущая система или текущий бизнес-процесс);

- наша ИС (положение об основном отличии и преимуществе новой ИС).

Пример:

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

3.1.6. Основные функции

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

3.1.7. Предположения и зависимости

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

3.1.8. Масштабы и ограничения проекта

Следует определить рамки и ограничения проекта. Вам необходимо указать, что может делать система, а что не может:

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

3.2. Разработка основных концептуальных решений по задаче (TO-BE)

-представить основные концептуальные решения по задаче, в первую очередь приводят диаграммы бизнес-процессов "TO-BE" с их описанием.

-диаграммы потоков данных, связанные с перечисленной в постановке задачи (подраздел 3.1) входной, промежуточной и выходной информацией.

-описать архитектуру задачи или подсистемы.

3.3. Анализ успешных ИТ - проектов в рассматриваемой области и обоснование выбора ИТ – решения

Основная задача этой части – обзор отечественного и мирового опыта построения ИС в данной предметной области.

3.4. Определение критериев для анализа

Обзор необходимо завершить анализом с точки зрения выбранных критериев, к которым можно отнести, например:

- цель проекта;

- задачи проекта;

- основные функции;

- стоимость проекта;

- время выполнения проекта;

- программная платформа;

- аппаратная платформа.

3.5. Выбор ИТ – решения

На основании анализа производится выбор ИТ - решения для поставленной задачи.

3.6. Описание метода решения задачи

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

-дается описание выбранного математического метода или модели.

3.7. Описание информационного обеспечения задачи

-внешнее информационное обеспечение. Разработать: системы классификации и кодирования информации, единую систему нормативно-справочной и оперативной документации, методические материалы по описанию документооборота.

-выбрать систему классификации для объектов описания и построить структуру кода для каждого объекта.

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

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

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

3.7.1. Бизнес – требования

Бизнес - требования содержат высокоуровневые цели организации или заказчиков системы. Их формирует тот, кто финансирует проект или покупает систему или менеджер реальных пользователей. Эти требования записываются в уставе проекта, который иногда называют документом об образе и границах проекта или документом рыночных требований. Шаблон бизнес - требований разработан IEEE.

IEEE – Institute of Electrical and Electronics Engineers - международная некоммерческая ассоциация специалистов в области техники, мировой лидер в области разработки стандартов по радиоэлектронике и электротехнике. Эта общественная некоммерческая ассоциация профессионалов ведёт свою историю с 1884 года, объединяет более 372000 индивидуальных членов из 170 стран, в том числе более 80000 студентов. IEEE издаёт третью часть мировой технической литературы, касающейся применения радиоэлектроники, компьютеров, систем управления, электротехники, в том числе (январь 2008) 102 реферируемых научных журнала и 36 отраслевых журналов для специалистов, проводит в год более 300 крупных конференций, принимала участие в разработке около 900 действующих стандартов.

3.7.2. Объем первоначально запланированной версии

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

3.7.3. Объем последующих версий

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

3.7.4. Ограничения и исключения

Определение границы между тем, что входит и выходит за границы проекта.

3.7.5. Профили заинтересованных лиц

Заинтересованными в проекте лицами называются отдельные лица, группы или организации, которые активно вовлечены в проект, на которых влияет результат проекта и которые сами могу" влиять на этот результат (Project Management Institute, 2000; Smitr, 2000). Профили заинтересованных лиц описывают различные категории клиентов и других ключевых лиц, заинтересованных в этом проекте. В профиль каждого заинтересованного в проекте лица включается следующая информация:

- основная ценность или преимущество, которое продукт принесет заинтересованным лицам и то, как продукт удовлетворит покупателей. Ценность для заинтересованных лиц может представлять:

1. улучшенная производительность;

2. меньшее количество переделок;

3. снижение себестоимости;

4. ускорение бизнес-процессов;

5. автоматизация задач, ранее выполнявшихся вручную;

6. возможность выполнять совершенно новые задачи;

7. соответствие соответствующим стандартам и правилам;

8. лучшая, по сравнению с текущими продуктами, легкость и простота использования;

- их вероятное отношение к продукту;

- наиболее интересные функции и характеристики;

- все известные ограничения, которые должны быть соблюдены.

3.7.6. Приоритеты проекта

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

- ограничение — лимитирующий фактор, в рамках которого должен оперировать менеджер проекта;

- ключевой фактор — важный фактор успеха, ограниченно гибкий при изменениях;

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

3.7.7. Операционная среда

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

1. Пользователи расположены далеко (географически) или близко друг от друга? В скольких часовых поясах работают ваши пользователи?

2. Когда пользователям, находящимся в различных географических местоположениях, требуется доступ к системе?

3. Где данные генерируются и используются? Насколько далеко друг от друга расположены эти местоположения? Нужно ли объединять данные из разных местоположений?

4. Известно ли максимальное время отклика для получения доступа к данным, которые могут храниться удаленно?

5. Готовы ли пользователи смириться с прерыванием работы службы или непрерывный доступ к системе крайне важен для работы их компании?

6. Какие элементы управления безопасностью и требования к защите данных необходимы?

3.8. Описание программного обеспечения задачи

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

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

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

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

Студент должен выбрать конкретный метод или методы тестирования и составить план тестирования (последовательность выполнения тестирования и применяемые на каждом этапе методы). В случае разработки или доработки программного обеспечения можно использовать методы белого ящика, методы черного ящика и методы серого ящика. В случае использования типового программного продукта - только методы черного ящика.

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

3.8.1. Требования пользователей

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

- уникальный идентификатор;

- имя, кратко описывающее задачи пользователя в формате «глагол + объект»;

- краткое текстовое описание на естественном языке;

- список предварительных начальных условий, которые должны быть удовлетворены до начала разработки варианта использования;

- выходные условия, описывающие состояние системы после успешного завершения разработки вариантов использования;

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

- приоритет, частота варианта использования и другие особые требования.

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

3.8.2.1. Назначение

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

3.8.2.2. Соглашения, принятые в документах

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

3.8.2.3. Предполагаемая аудитория и рекомендации по чтению

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

3.8.2.4. Границы проекта

Можно сослаться на документ об образе и границах.

3.8.2.5. Ссылки

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

3.8.3. Общее описание

3.8.3.1. Общий взгляд на продукт

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

3.8.3.2. Особенности продукта

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

3.8.3.3. Классы и характеристики пользователей

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

3.9. Техническое обеспечение проекта и инфраструктура

3.9.1. Описание общесистемной программной среды реализации проекта

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

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

3.9.2. Описание технического обеспечения и вычислительной среды проекта

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

3.9.2.1. Операционная среда

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

3.9.2.2. Ограничения дизайна и реализации

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

- определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать;

- ограничения, налагаемые операционной средой продукта, например, типы и версии установленных Web-браузеров;

- обязательные соглашения или стандарты разработки (например, если обслуживать ПО будут клиенты, то они должны указать особенности дизайна и стандарты программирования, которые субподрядчик обязан соблюдать);

- обратная совместимость с продуктами, выпущенными ранее;

- ограничения, налагаемые бизнес-правилами;

- ограничения, связанные с оборудованием, например, требования к срокам, ограничения памяти или процессора, размер, вес, материалы или затраты;

- соглашения, связанные с пользовательским интерфейсом существующего продукта, которые необходимо соблюдать при улучшении существующего продукта;

- стандартный формат обмена данными, например, XML.

3.9.2.3. Документация для пользователей

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

3.9.2.4. Предположения и зависимости

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

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

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

3.9.3. Техническое обеспечение

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

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

3.9.3.1. Функции системы

Поиск по сайту: