Ответы_к_госам_final

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

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

Microsoft Visual SourceSafe (Visual SourceSafe, VSS) — программный продукт компании Майкрософт, файл-серверная система управления версиями, предназначенная для небольших команд разработчиков. VSS позволяет хранить в общем хранилище файлы, разделяемые несколькими пользователями, для каждого файла хранится история версий.

CVS (Concurrent Versions System, «Система Одновременных Версий») — программный продукт, относящийся к разряду систем управления версиями (англ. version control system). Хранит историю изменений определѐнного набора файлов, как правило,исходного кода программного обеспечения, и облегчает совместную работу группы людей (часто — программистов) над одним проектом.

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

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

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

1 Планирование коммуникаций – определение потребностей участников проекта в коммуникации и информации.

2 Распространение информации – своевременное предоставление необходимой информации участникам проекта.

3 Отчетность по исполнению – сбор и распространение информации о выполнении работ. Эта информация включает в себя отчеты о текущем состоянии, оценку прогресса и прогнозирование.

4 Управление участниками проекта – управление коммуникациями в целях удовлетворения требований участников проекта и решения возникающих проблем.

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

внутренние (внутри команды проекта) и внешние (с руководством компании, заказчиком, внешними организациями и т. д.);

формальные (отчеты, запросы, совещания) и неформальные (напоминания, обсуждения);

письменные и устные;

вертикальные и горизонтальные.

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

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

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

Документирование результатов хода работ включает в себя:

сбор и верификацию окончательных данных;

анализ и выводы о степени достижения результатов проекта и эффективности выполненных работ;

архивирование результатов с целью дальнейшего использования.

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

Средства управления проектом

См. ПО для управления проектом

МОДЕЛИРОВАНИЕ СИСТЕМ

Моделирование при автоматизации предприятия: подходы, методы, средства.

Цели моделирования и этапы разработки проектов

Целью модели является получение ответов на некоторую совокупность вопросов.

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

анализ – определение того, что система будет делать;

моделирование – определение подсистем и их взаимодействие;

реализация – разработка подсистем по отдельности,

объединение - соединение подсистем в единое целое;

тестирование – проверка работы системы;

установка – введение системы в действие;

функционирование – использование системы.

Таким образом, основными целями моделирования при разработке

нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения;

технологий работы подразделений предприятия и его взаимодействию с

внедрению существующих систем управления предприятиями.

Понятие модели

М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.

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

Классификация моделей.

Признаки классификаций моделей: 1) по области использования;

2) по фактору времени;

3) по отрасли знаний;

4) по форме представления

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

Врамках данного этапа осуществляется:

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

определение оргштатной и топологической структур предприятия;

определение перечня целевых задач (функций) предприятия;

анализ распределения функций по подразделениям и сотрудникам;

определение перечня применяемых на предприятии средств

автоматизации.

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

В качестве исходной информации при проведении обследования и выполнении дальнейших этапов служат:

данные по оргштатной структуре предприятия;

информация о принятых технологиях деятельности;

стратегические цели и перспективы развития;

результаты анкетирования сотрудников (от руководителей до исполнителей нижнего звена);

предложения сотрудников по усовершенствованию бизнеспроцессов предприятия;

нормативно-справочная документация;

опыт системных аналитиков в части наличия типовых

решений.

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

Построение моделей деятельности предприятия

На данном этапе осуществляется обработка результатов обследования

ипостроение моделей деятельности предприятия следующих двух видов:

модели “как есть”, представляющей собой "снимок"

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

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

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

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

Переход от модели ―как есть‖ к модели ‖как должно быть‖ осуществляется следующими двумя способами:

1.Совершенствование технологий на основе оценки их

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

2.Радикальное изменение технологий и переосмысление

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

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

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

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

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

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

Данный этап является первой фазой разработки собственно системы автоматизации.

На этом этапе определяются:

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

интерфейсы и распределение функций между человеком и системой;

требования к программным и информационным компонентам

системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонентов системы, их интерфейсы;

состав людей и работ, имеющих отношение к системе;

ограничения в процессе разработки (директивные сроки завершения

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

Системный проект строится на основе модели “как должно быть” и включает функциональную модель будущей системы в соответствии с одним из общеупотребительных стандартов , информационную модель, а также техническое задание на создание автоматизированной системы (например, в соответствии с ГОСТ 34.602-89).

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

описать, "увидеть" и скорректировать будущую систему до того, как она будет реализована физически;

уменьшить затраты на разработку и внедрение системы;

оценить разработку по времени и результатам;

достичь взаимопонимания между всеми участниками работы

(заказчиками, пользователями, разработчиками, программистами и т.д.); улучшить качество разрабатываемой системы, а именно: создать

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

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

Разработка предложений по автоматизации предприятия.

На основании системного проекта осуществляется:

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

 совместное с заказчиком принятие решения о выборе конкретной системы управления предприятием или разработке собственной

Разработка технического проекта

На данном этапе на основе системного проекта и принятых решений по автоматизации осуществляется моделирование системы. Фактически здесь дается ответ на вопрос: "Как (каким образом) мы будем строить систему, чтобы она удовлетворяла предъявленным к ней требованиям?". Этот этап разделяется на два подэтапа:

 моделирование архитектуры системы, включающее разработку структуры и интерфейсов ее компонентов (автоматизированных рабочих мест), согласование функций и технических требований к компонентам, определение информационных потоков между основными компонентами, связей между ними и внешними объектами;

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

При этом происходит расширение системного проекта:

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

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

Жизненный цикл автоматизированной информационной системы

Этапы жизненного цикла АИС

Модели жизненного цикла информационной системы

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

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