Разработка системного проекта новой ИС и определение методов и инструментальных средств дальнейшего детального проектирования и сопровождения всего жизненного цикла ИС

Последним этапом начальной стадии проектирования является создание системного проекта, определяющего (закрепляющего) методы и средства дальнейшего детального проектирования и поддержки ЖЦИС.

Работы по разработке системного проекта регламентированы следующими документами:

· ГОСТ 34.602, РД 50-34 698-90 п. 2.11, 2, 3.1;

· ГОСТ Р ИСО/МЭК 12207 – 99 п. 5.1.3, 5.2.4, 5.3.3, 5.2.3, 5.3.4, 5.3.5, 5.3.6, 7.1, 7.4, приложения А и Б.

· ISO-90003 п. 4, 5.

Перечень и порядок работ могут быть следующими: Липаев - 4.3 – «Методика разработки проектирования комплекса программ новой ИС»

Рассмотрим подробно проблему выбора и описания архитектуры ИС.

Под выбором архитектуры понимают выбор платформы (платформ) и выбор ОС. В системе могут работать несколько компьютеров на разных аппаратных платформах и под управлением разных ОС.

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

Менять платформу, ОС или СУБД на этапе реализации сложно, а на этапе опытной эксплуатации – невозможно. Чем больше компонентов в системе реализовано, тем сложнее произвести замену. Перенос ПО на ту или иную платформу и управление разнородной сетью – процесс сложный.

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

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

Кроме определения платформ, следует выяснить следующее:

1. будет ли это архитектура файл-сервер или клиент-сервер;

2. будет ли это трехуровневая архитектура со следующими областями: сервер, ПО промежуточного слоя (сервер приложений), клиентские ПО;

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

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

5. если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей;

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

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

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

Это позволит:

1. разбить глобальную задачу на небольшие относительно независимые задачи. Ими легче управлять и их легче реализовывать.

2. определить контрольные даты сдачи (этапы сдачи, которые позволят узнать, насколько успешно продвигается проект, какие направления отстают и (или) недогружены, а какие работают успешно). Это позволит обнаружить отставания от сроков сдачи и предотвратить авралы.

3. определить зависимости между задачами, а так же последовательность задач.

4. прогнозировать загрузку персонала, наем временных работников.

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

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

Детальное проектирование ИС

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

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

Сопровождение всего ЖЦ ИС….

 

24. Автоматизированное проектирование ИС на основе функционально-ориентированного и объектно-ориентированного подходов с использованием CASE-технологий (мало)

Автоматизированное проектирование ИС на основе функционально-ориентированного и объектно-ориентированного подходов с использованием CASE-технологий. Построение моделей (SADT-функциональная; DFD; ERD; STD; eEPC; вариантов использования; прецедентов и т.д) в зависимости от используемых CASE-технологий на соответствующих этапах проектирования ИС.

 

 

Моделирование и анализ бизнес-процессов

25. Функциональный и процессный подходы к управлению организацией

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

Структурный подход

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

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

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

Недостатки структурного подхода

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

· отсутствие цельного описания технологий выполнения работы, в лучшем случае существует только фрагментарная (на уровне структурных элементов), и то не совсем актуальная документируемость технологий;

· отсутствие ответственного за конечный результат и контроль над технологией в целом, а также ориентации на клиента (внешнего или внутреннего);

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

· высокие накладные расходы, как правило, непонятно откуда появляющиеся;

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

Функциональный подход

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

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

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