Презентации, доклады, проекты по информатике

История возникновения методологии IDEF0
История возникновения методологии IDEF0
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвящанная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition).  В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках “аналитик-специалист”. Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта.
Продолжить чтение
Тест-сеты, тест-сьюты и тест-кейсы. Правила их составления. Практическое занятие. Лекция 10 (ч. 1)
Тест-сеты, тест-сьюты и тест-кейсы. Правила их составления. Практическое занятие. Лекция 10 (ч. 1)
Содержание занятия: Что такое тест-сет, тест-сьют и тест-кейс. Правила оформления тест-кейсов. Практическое занятие 6: Создание тест-сета. Написание первого тест-кейса. Тест-сет (Test Set, TS) – набор тестовых сценариев полученных на основании внутренней структуры компонента или спецификации, предназначенный для убеждения в 100% достижении заданных критериев покрытия (Smoke, Regression Testing). Тест-сьют (Test Suite, TS) – комплект тестовых наборов для исследуемого компонента или системы, в котором обычно постусловие одного теста используется в качестве предусловия для последующего (Feature Testing). Тест-кейс (Test Case, TC) – набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610]
Продолжить чтение
Формирование каталога CТЕ для Портал поставщиков
Формирование каталога CТЕ для Портал поставщиков
Цели и задачи проекта Государственное бюджетное учреждение города Москвы «Аналитический центр»/ 2019 Основание: Постановление Правительства Москвы N 1292-ПП от 24 октября 2018 г. «Об автоматизированной информационной системе "Портал поставщиков». Регламент ведения Портала Поставщиков, утвержденный приказом Департамента города Москвы по конкурентной политике от 28.06.2019 г. № 70-01-119/19. Соглашение о передаче отдельных функций уполномоченного органа, осуществляющего координацию информационного наполнения автоматизированной информационной системы «Портал поставщиков» от 19.04.2019 г. Цель: Реализация механизмов единой классификации, учета и аналитики товаров, работ, услуг, закупаемых заказчиками города Москвы. Задачи: Создание актуального справочника товаров, работ, услуг, которые могут закупаться для нужд Заказчиков Формирование единого справочника характеристик и обмен характеристик между ЕАИСТ и ПП Формирование в электронном магазине перечня СТЕ (корзины СТЕ) для использования в конкурентных процедурах Формирование контракта со структурированной спецификацией на основе СТЕ по типовому шаблону для заказчиков ЕАИСТ и переход от формата СТЕ по комплексным работам, услугам к котировочным сессиям. Состав проектной команды Государственное бюджетное учреждение города Москвы «Аналитический центр»/ 2019 Заказчик проекта: Тетушкин Дмитрий Николаевич Руководитель проекта: Гиняев Булат Рустемович Исполнители: Начальник отдела, сотрудники отдела администрирования и информационного наполнения автоматизированных информационных систем Проектного офиса № 5 "Администрирование, ведение и сопровождение информационных ресурсов". Эксперты:
Продолжить чтение
Стоимостные характеристики информационной деятельности. Правовые нормы
Стоимостные характеристики информационной деятельности. Правовые нормы
В некоторых случаях требуется покупка информации. Коммерческим компаниям бывает необходима информация, которая может повлиять на процесс управления и сам бизнес. К такого рода информации относятся сведения  о ценах на рынках и промышленных стандартах в странах, где компания ведет свой бизнес. В связи с этим возникает вопрос о стоимости информации. У различных компаний в случае применения одной и той же исходной информации при ведении бизнеса результаты будут разными. Соответственно и экономия от этой информации будет отличаться Информацию нельзя измерять только количественными характеристиками, т.к. качество ее различно, следовательно, различна и её стоимость. В информационном обществе повышается значение информации как товара. Стоимость информации как товара определяется трудом, вложенным в его производство. Потребности управления любой компании в информации практически не ограничены. Приобретение дополнительной информации приводит, как правило, к серьезным затратам.
Продолжить чтение
Автоматизация запроса персональных данных пациента, предоставление личных данных страховщику и верификация цифровых документов
Автоматизация запроса персональных данных пациента, предоставление личных данных страховщику и верификация цифровых документов
Преимущества использования подхода Страховщику не требуется иметь договора с различными МИС об обработке персональных данных пациента – пациент САМ предоставляет их при запросе услуги. У страховщика ВСЕГДА актуальные данные – каждый раз при запросе услуги приложение SIRIUS передает самые актуальные данные, поскольку авторизация в МИС происходит также через SIRIUS, а значит и скачивает самые последние данные. Страховщик Свободен в формировании запроса, какие данные ему нужны от клиента (возраст, история болезней), у страховщика имеется информация, какие данные ВООБЩЕ можно вытащить из документов МИС, и на основе этих данных формировать свои внутренние документы в цифровом виде Решен вопрос безопасности – страховщик не хранит личные данные, данные в принципе могут не иметь прямой ссылки на имя пациента (если такая необходимость есть, в запросе можно убрать имя фамилию клиента), все взаимоотношения через BitCoin – адрес. Как только данные более не нужны для предоставления услуги – их можно удалить, поскольку они все равно хранятся в приложении SIRIUS Страховщик при формировании услуги и стоимости может учитывать, данные каких МИС он хочет учитывать или не учитывать. Страховщик может менять версии своих документов, добавлять новые МИС, добавлять новые данные, удалять более не актуальные для нег МИС Поскольку SIRIUS это не только хранилище персональных данных, управленец может настраивать СКВОЗНОЙ КОНТРОЛЬ бизнес процессов – автоматизированные помощники с оповещением о критических событиях, групповые переписки, корпоративные чат.
Продолжить чтение