Case-средства.
Ответ: Разработчикам необходимы средства для автоматизированного проектирования и создания программ или так называемые CASE-средства (Computer Assisted Software Engineering – CASE). CASE – средства позволяют хранить и получать доступ к моделям через центральный репозиторий, а также манипулировать этими моделями на экране компьютера в графическом и текстовом режимах. В идеале репозиторий должен обеспечивать одновременный доступ многих пользователей (многих разработчиков) к моделям.
Перечень типичных функций CASE-средств (репозитория).
координация доступа к моделям.
помощь в организации взаимодействия между разработчиками.
хранение нескольких версия моделей.
идентификация различий между версиями.
возможность совместного использования одних и тех же концептов в различных моделях.
проверка непротиворечивости и целостности моделей.
генерация проектных отчетов и документов.
генерация структур данных и программного кода (конструирование ПО)
генерация моделей по существующей реализации (реконструкция ПО) и.т.д.
Следует отметить, что зачастую программа, сгенерированная с помощью CASE средств, представляет собой на самом деле всего лишь «скелет» программы – вычислительный алгоритм, который необходимо дорабатывать программисту как при обычном программировании.
Совершенствование процесса – это нечто большое, чем просто введение новых методов и средств. В действительности, введение новых методов и средств в организации, находящейся на низком уровне зрелости процесса разработки, может принести больше вреда чем пользы.
Подходящий пример – CASE – технологии. Интегрированные CASE-средства позволяют нескольким разработчикам взаимодействовать и совместно использовать проектную информацию для выработки новых проектных артефактов. Чтобы воспользоваться преимуществами этой технологии, бригада разработчиков должна подчиняться определенным правилам, поскольку CASE-средства налагают на процессы некоторые ограничения. Но если группа проекта не настолько квалифицированна, чтобы усовершенствовать процесс разработки, чрезвычайно маловероятно, чтобы она смогла воспринять процесс, диктуемый CASE-средствами. В результате потенциальные возможности роста продуктивности и качества, которые обещает новая технология, так и не будут реализованы.
Рассмотренные выше особенности применения CASE-средств не должны натолкнуть вас на мысль, что CASE-технология – «рискованное дело». Она может и не дать вам ожидаемых выгод, если вы пытаетесь использовать ее для того, чтобы направлять работу всей группы проекта, а группа проекта не готова следовать нужному процессу. Однако, те же методы и CASE – средства безусловно могут обеспечить повышение личной продуктивности и качества работы отдельных разработчиков, которые используют технологию на своих локальных рабочих станциях. Моделировать программные артефакты с помощью карандаша и бумаги уместно только в аудитории, но никак ни при работе над реальным проектом.
Архитектура CASE-средства
Архитектура CASE-средства состоит из 6 компонентов:
Репозиторий данных
Графический редактор диаграмм
Верификатор диаграмм
Документатор проекта
Администратор проекта
Сервис
Репозиторий данных
Является специализированной базой данных для отображения состояния проектируемой ЭИС в любой момент времени. В нём хранится информация об объектах проектироуемой системы и все подсистемы обмениваются данными с ним.
Графический редактор диаграмм
Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет:
создавать элементы диаграмм и взаимосвязи между ними
задавать описания элементов диаграмм
задавать описания связей между элементами диаграмм
редактировать элементы диаграмм, их взаимосвязи и описания
Верификатор диаграмм
Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет:
мониторинг правильности построения диаграмм
диагностику и выдачу сообщений об ошибках
выделение на диаграмме ошибочных элементов
Документатор проекта
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчётов. Отчёты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.
Администратор проекта
Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:
инициализация проекта
задания начальных параметров проекта
назначения и изменения прав доступа к элементам проекта
мониторинга выполнения работ
Сервис
Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория.
Требования к системе FURPS+.
Ответ: Требования (requirements) – это возможности или условия, которым должна соответствовать система или проект. Основная задача этапа определения требований – найти, обсудить и зафиксировать, что действительно требуется от системы в форме, понятной и заказчикам ПО и членам команды разработчиков.
Существует несколько принципов систематизации требований и перечня атрибутов качества. Применительно к программным системам предложена следующая классификация требований, которая получила название модели FURPS+, что соответствует первым буквам соответствующих категорий требований на английском языке:
– функциональные требования (Functionality) – свойства, возможности, безопасность;
– требования к удобству использования (Usability) – человеческий фактор, справочная система, документация;
– требование к надежности (Reliability) – частота сбоев, возможность восстановления и предсказуемость поведения;
– требования к производительности (Performance) – время отклика, точность, доступность использования ресурсов;
– требования возможности сопровождения (Supportability) – адаптивность, возможность поддержки, соответствие международным стандартам, возможность конфигурирования, возможность расширения.
При этом символом “+” обозначены дополнительные условия, к которым относятся:
– проектные ограничения;
– требования управления системой;
– требования к графическому интерфейсу пользователя;
– физические требования;
– юридические требования – авторское право и т. п.
Помимо такой классификации требования делят на две большие категории: функциональные (относящиеся к поведению) и нефункциональные (все остальные). Центральное место среди указанных требований занимают функциональные, которые специфицируют особенности реализации отдельных бизнес-процессов моделируемой системы.
Требования к системе фиксируют в техническом задании – текстовом документе, в котором описывается разрабатываемая система. В этом документе содержится информация о том, что именно пользователи хотят получить от этой системы. В соответствии с этим документом заказчик будет оценивать готовую систему. Документ должен быть достаточно детальным, чтобы на его основе пользователь смог реально оценить полноту системы. В нем необходимо привести соответствующие сведения, которые будут использоваться проектировщиками на этапе проектирования системы.
Однако в техническом задании могут содержаться некоторые неточные сведения о разрабатываемой системе, поэтому часто составляется еще один документ – требования к системе. Требования должны формировать окончательное представление о разрабатываемой системе. Все последующие документы, создаваемые в процессе разработки системы, будут основываться именно на этих требованиях.
Помимо требований, классифицированных по модели FURPS+, полезно рассмотреть следующие вопросы:
– cовместимости (система должна быть совместима с существующими и проектируемыми информационными системами для данного объекта);
– масштабируемости (свойство, характеризующее поведение системы при добавлении ресурсов (обычно аппаратных) – масштабируемой принято считать систему, производительность которой возрастает пропорционально объему приобщенных ресурсов;
– адаптируемости, гибкости и возможности настройки под конкретные нужды пользователей;
– высокой степени защищенности информации от несанкционированного доступа и сбоев оборудования;
– единой внутренней логики работы системы, открытость для внесения необходимых изменений, устойчивость к организационным изменениям;
– обеспечения разделенного доступа пользователей к ресурсам системы и обеспечение сетевого режима функционирования;
– обеспечения ясности и простоты логической организации данных.
Требования оказывают существенное влияние на архитектуру разрабатываемой системы. Например, требования высокой производительности или надежности влияют на выбор программного обеспечения и аппаратных средств.