Главная страница
Навигация по странице:

  • Вывод: Я научился делать техническое задание по производственной практики. Дата

  • 2. SDT

  • Вывод: Я научился делать и описывать STD и SATD диаграммы. Дата

  • Функциональные требования

  • Нефункциональные требования

  • Нефункциональные требования: как их определять

  • Системный аналитик

  • Вывод: Я научился делать DFD диаграммы

  • работа. Изучение предметной области разработки программного обеспечения


    Скачать 437.2 Kb.
    НазваниеИзучение предметной области разработки программного обеспечения
    Анкорработа
    Дата04.07.2022
    Размер437.2 Kb.
    Формат файлаdocx
    Имя файлаTekhnicheskoe_zadanie 15-27 kurepko.docx
    ТипДиплом
    #624612
    страница2 из 6
    1   2   3   4   5   6

    Дополнительные факторы безопасной доставки


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

    Дата 17.06.2022
    Диаграммы переходов состояний STD и функциональные диаграммы SADT


    1.SADT Диаграмма

    Диаграмма является основным рабочим элементом при создании модели. Разработчик диаграмм и моделей обычно называется аналитиком, или, в терминологии SADT, автором. Диаграммы имеют собственные синтаксические правила, отличающиеся от синтаксических правил моделей. Важно их хорошо понимать, поскольку графические обозначения имеют особый смысл. Вы увидите, что графика SADT позволяет определить различные системные функции и показать, как функции влияют друг на друга. Эта книга посвящена только функциональным SADT-диаграммам, поэтому в данной главе обсуждаются синтаксические правила только для функциональных SADT-диаграмм. Функциональные блоки на диаграммах изображаются прямоугольниками. Блок представляет функцию или активную часть системы, поэтому названиями блоков служат глаголы или глагольные обороты. Например, названиями блоков диаграммы выполнить задание являются: определить степень выполнения задания, выбрать инструменты, подготовить рабочее место, обработать на станке и собрать.



    2.SDT Диаграмма

    SDT демонстрирует поведение разрабатываемой программной системы при получении управляющих воздействий (извне).

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

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

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

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



    Вывод: Я научился делать и описывать STD и SATD диаграммы.
    Дата 18.06.2022

    Анализ функциональных и нефункциональных требований.

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

    Функциональные требования

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

    Нефункциональные требования

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

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

    В то время как функциональные требования определяют, что делает система, нефункциональные требования описывают, КАК система это делает. Например, веб-приложение должно обрабатывать более 15 миллионов пользователей без какого-либо снижения производительности, или веб-сайт не должен загружаться более 3 секунд.

    Нефункциональные требования: как их определять




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

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

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

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

    • Системный аналитик — собирает, анализирует и документирует и систематизирует нефункциональные требования.

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

    • Группа тестирования — участвует в определении и анализе нефункциональных требований и разрабатывает сценарии тестирования для проверки нефункциональных требований

    Пример DFD-модели



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

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

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

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

    Функциональная схема или схема данных (ГОСТ 19.701-90)– схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом. Функциональные схемы, более информативны, чем структурные. Все компоненты структурных и функциональных схем должны быть описаны.

    Вывод: Я научился делать DFD диаграммы

    Дата:20.06.2022
    1   2   3   4   5   6


    написать администратору сайта