Островский, К. А. Типы требований к Web-приложению для обработки экспериментальных данных / К. А. Островский. — Текст : непосредственный // Молодой ученый. — 2010. — № 5 (16). — Т. 1. — С. 101-103. — URL: https://moluch.ru/archive/16/1568/ (дата обращения: 31.05.2023).
Обработка экспериментальных данных в наше время чаще всего проводится с использованием вычислительных машин. Однако целевые пакеты предназначены либо для выполнения на локальной машине исследователя, либо реализуются с помощью GRID-технологий, что лишает их преимуществ перед современным типом программ – Web-приложениями. Среди этих преимуществ можно выделить следующие:
§ кроссплатформенность – не имеет значения, какой программной средой или аппаратной платформой располагает пользователь, т.к. для работы с приложением необходим только браузер;
§ в отличие от классических приложений, пользователь не заботится об установке и настройке пакета;
§ коллективная работа и синхронное взаимодействие – единый формат представления, единая терминология, поддержка системой объединения результатов различных этапов исследования, организация связи с помощью чата и видеоконференция позволяют исследователям эффективно взаимодействовать в независимости от их местоположения;
Что такое функциональные требования ? Четкая постановка задач разработчику
§ обновление пакета не требует каких-либо действий со стороны пользователя;
§ обеспечение надежности хранения данных при сбое аппаратуры клиентских компьютеров;
§ не требовательность к ресурсам терминала – все действия над данными выполняются на удаленном сервере, где хранится приложение;
§ увеличение мощности вычислительной системы прозрачно для пользователя и может производиться без прерывания обслуживания.
В рамках магистерской диссертации автору необходимо разработать Web-приложение для обработки экспериментальных данных. Разработка программного обеспечения (ПО) подчиняется определенному жизненному циклу (lifecycle), т.е. упорядоченному набору видов деятельности, осуществляемому и управляемому в рамках каждого проекта по разработки ПО, где процессы и методы – механизмы реализации жизненного цикла[1, c, 46]. Существует множество подходов реализации жизненного цикла разработки (например, такие как SWOT, VCM, BPR, ISA и т.д.), но всех их объединяет наличие этапа определения требований к программной системе. Недостаточный объем информации, поступающей от пользователей, требования, сформулированные не полностью, их кардинальное изменение после начала проектирования являются основными причинами, из-за которых нарушаются сроки разработки и рамки бюджета, чтобы предоставить пользователям полнофункциональный продукт.
Под требованиями к программному обеспечению будем понимать совокупность утверждений относительно свойств программной системы, подлежащая реализации при создании ПО[3]. Изучение литературных источников выявляет несколько основных проблемы, осложняющих разработку требований:
§ проблема отсутствия общепринятых определений терминов;
§ существующие классификации хорошо работают в условиях крупных проектов, однако являются избыточными для проектов малого масштаба;
Сколько стоит разработать мобильное приложение? Реальная стоимость разработки приложения.
§ создаются только бизнес-ориентированные классификации требований.
Ввиду этих причин автор, опираясь на работы [1] и [2], определил свои типы требований к разрабатываемой системе, иерархический список которых, изображен на рисунке 1. Все типы требований разделены на три основных класса:
1. требования к средствам обеспечения и поддержки функционирования – содержит типы требований, определяющие программные и аппаратные средства или их уровни, в рамки которых должно вписаться разрабатываемое приложение.
2. Функциональные требования содержат типы требований, определяющие целевые возможности системы, т.е. ограничивает круг непосредственно решаемых с помощью продукта задач.
3. Требования общего характера.
Поясним типы требований, содержащиеся в этих классах:
§ требования к аппаратным средствам, определяют их уровень производительности, тип архитектуры, емкость хранилища, а также пропускную способность канала связи, обеспечивающую комфортную работу с приложением;
§ требования к программной платформе во многом определяют инструментарий разработки, влияют на выбор СУБД;
§ требования к системе хранения данных – выбор СУБД будет влиять на уровень производительности приложения, затраты на обслуживание, объемы данных с которыми сможет оперировать система;
§ требования к информационной безопасности определяют наличие или отсутствие системы авторизации и аутентификации, а также других средств защиты;
Рисунок 1 — Классификация и типы требований к разрабатываемому приложению
§ требования к реализуемым методам обработки экспериментальных данных определяют состав методов и приемов обработки данных. Примерами этих средств являются аппараты математической статистики и интеллектуального анализа данных (Data mining);
§ требования к видам и размерностям величин, т.е. с какими типами данных и каких пределах их варьирования должно быть способно работать приложение;
§ требования к подсистеме визуализации определяет то, в каком виде могут представляться входные и выходные данные;
§ требования к совместимости с форматами файлов других приложений определяют возможности импорта и экспорта данных (межпрограммное взаимодействие);
§ требования к организации совместной работы определяют, какие средства межпользовательского взаимодействия должна поддерживать система;
§ требования к расширяемости позволяют определить, если необходимо, как обеспечиваются дополнительные возможности – с помощью дополнительных модулей (плагинов), с помощью языка написания сценариев и т.п.;
§ требования к интерфейсу пользователя определяют то, как происходит взаимодействие пользователя с приложением;
§ требования к затратам на обслуживание системы позволяют ограничить бюджет, который необходим для поддержания функционирования системы в течение эксплуатационного периода.
Таким образом, в статье была предложена классификация требований к Web-системе обработки экспериментальных данных, последующая конкретизация которых может быть реализована, например, с помощью средств СППР. Это позволит ограничить объем работы по проектированию, создать адекватную этим требованиям архитектуру приложения и оптимально распределить сроки разработки.
1. Мацяшек, Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. – М.: Издательский дом «Вильямс». 2002. – 432 с.: ил. – Парал. тит. англ.
2. Вигерс Карл Разработка требований к программному обеспечению/Пер. с. англ. – М.: Издательско-торговый дом «Русская редакция», 2004. – 576 с.: ил.
3. Требования к программному обеспечению – Википедия [Электронный ресурс] : свободная общедоступная многоязычная универсальная энциклопедия. – Режим доступа: http://ru.wikipedia.org/wiki/Требования_к_программному_обеспечению. — Загл. с экрана.
Основные термины (генерируются автоматически): тип требований, программное обеспечение, Требование, BPR, ISA, SWOT, UML, VCM, программная система, Разработка требований.
Похожие статьи
Разработка объектно-ориентированной модели процесса.
Основой разработки любого проекта, в том числе проекта сложно программно-информационной системы, является определение и формулировка требований.
Программное обеспечение системы менеджмента качества
Ключевые слова: система менеджмента качества, программное обеспечение, софтвер.
Софтверы являются бюджетным решением для небольших компаний, однако, они отвечают лишь некоторым требованиям стандартов ISO.
Методологии проектирования мультиагентных систем
1) Разработка моделей типа X-машина (типов агентов X-машины).
‒ Сложность формализации требований. Выводы. В данной статье были рассмотрены методологии проектирования мультиагентных систем, в том числе, применительно к созданию.
Особенности процесса развертывания программного.
Особенности процесса развертывания программного обеспечения в условиях интенсивной разработки.
Новые требования к развертыванию ПО, продиктованные развитием технологий и методологий разработки, включают в себя постоянную готовность и непрерывность.
Методы и средства проектирования информационных систем
В настоящее время в рамках проектирования сложных высоконагруженных систем используется спиральная модель разработки жизненного цикла программного обеспечения, поскольку классическая каскадная модель не удовлетворяет современным требованиям к.
Подход к моделированию процессов функционирования систем.
При проектировании систем защиты информации выполняется ряд работ, направленных на анализ возможных угроз и каналов утечки конфиденциальной информации
− наличие жестких требований методологии, обеспечивающих получение моделей процессов стандартного вида
Модель управления и автоматизации этапов жизненного цикла.
Система разработки и постановки продукции на производство. Термины и определения» [2], «Руководство к Своду знаний по управлению
— участие в жизненном цикле различного как программно-аппаратного обеспечения, так и проектного и эксплуатирующего персонала.
Формирование навыков аналитики IT-специальностей.
. на основе Unified Modeling Language (UML) и Business Process Model and Notation (BMPN), документирования процессов разработки и их
— выявлять требования пользователей; — осуществлять разработку качественных требований к программному продукту, задавать.
Повышение точности и сокращение времени планирования.
требование, базовый метод, модель трассировки, система, описание требований, программное обеспечение, структура требований, предметная область, контроль ошибок, основание спецификаций требований.
- Как издать спецвыпуск?
- Правила оформления статей
- Оплата и скидки
Источник: moluch.ru
Требования к разработке ПО. Почему вам нужно разбираться в них? Часть 2
Перевод второй части статьи «Why You Need to Understand Software Requirements as a Software Engineer».
Первую часть можно найти по ссылке.
Классификация требований к ПО
Когда требования собраны, команда, которая будет заниматься проектом, может приступить к их классификации и разбивке на категории.
Благодаря классификации требований можно точнее оценить сроки и определить компоненты решения. В процессе работы у вас также могут появиться идеи, касающиеся реализации проекта.
Требования к ПО могут быть:
1. Функциональными и нефункциональными.
- Функциональные требования описывают функции, которые должно выполнять ПО. Например, предоставлять канал коммуникации для пользователя или переводить данные из одного формата в другой. То есть, речь идет о функционале продукта.
- Нефункциональные требования касаются таких вещей, как доступность, надежность, способность к восстановлению, поддерживаемость, масштабируемость, производительность, безопасность и прочие «…ость».
2. Производными и навязанными.
- Вытекает ли это требование из других требований?
- Это требование было явно и недвусмысленно высказано стейкхолдерами?
3. Ориентированными на продукт или на процесс его разработки.
- «Программа должна проверять права пользователя» — это требование к продукту.
- «Программа должна разрабатываться инкрементально. В ходе разработки должна использоваться непрерывная интеграция» — это требование к процессу.
4. Разной приоритетности. Для назначения приоритета может использоваться шкала с фиксированными значениями «обязательно», «крайне желательно», «желательно» и «необязательно».
5. Разного масштаба. Одни требования касаются проектирования отдельных компонентов, другие — архитектуры всего ПО. Нефункциональные требования чаще всего касаются всей программы в целом.
6. Изменчивыми или стабильными. Например, изначально может быть ясно, что требования будут меняться в ходе жизненного цикла продукта. В таком случае реализация программы должна быть толерантной к внесению изменений.
Валидация требований
Когда требования выяснены и классифицированы, нужно проверить их, обсудив со стейкхолдерами. Вы должны быть уверены, что поняли и записали все точно и что требования в целом действительно удовлетворяют нужды стейкхолдеров. Требования, которые не прошли валидацию, являются всего лишь «хотелками» тех, кто их высказал.
Если вы практикуете итеративную разработку, валидация требований будет осуществляться регулярно, при этом будут обсуждаться требования, касающиеся отдельных частей решения, т. е., они будут разбиты на логичные группы.
Обычно для проверки требований команда, реализующая решение, воспроизводит свое понимание требований стейкхолдерам. При этом может применяться начальный проект (бизнес-проект или технический, или даже оба), на котором показывается, как будут реализованы нужды стейкхолдеров.
Такие обсуждения для выяснения, все ли правильно всё поняли, устраиваются итеративно на этапах планирования. Обычно в них участвуют кросс-функциональные команды (дизайнеры, бизнес-аналитики, технические эксперты).
В некоторых случаях перед реализацией может потребоваться дополнительная подготовительная работа. Чтобы лучше продемонстрировать, как команда понимает требования, создается функциональный прототип.
В ходе валидации может выясниться, что команда не может полностью удовлетворить все требования каждого стейкхолдера. Ваша задача (как технического эксперта) — продемонстрировать, что можно сделать, и обсудить уступки, на которые можно пойти при существующих ограничениях. Эти компромиссы должны быть приемлемыми для главных стейкхолдеров, а также укладываться в рамки бюджета, технических возможностей и прочих ограничений.
Использование функциональных прототипов
Функциональные прототипы помогают нам:
- проверить, что требования поняты правильно;
- проверить допущения разработчика;
- получить фидбэк, в котором могут содержаться новые требования.
Вы должны учитывать, что чисто внешние проблемы или проблемы, связанные с качеством, могут отвлечь стейкхолдеров. Следует постоянно подчеркивать, что именно основной функционал является самым важным в этом показе.
То, как создается прототип, определяется командой, которая занимается проектом. Кто-то предпочитает прототипы, в которых вообще не задействовано ПО (аналогичные тем, которые создаются при сборе требований). Другие отдают предпочтение специальным инструментам, с помощью которых можно быстро создать «черновик» будущей программы.
Какой бы вариант вы ни выбрали, следует учитывать, сколько времени уйдет на создание прототипа, и насколько эффективно он продемонстрирует основной функционал.
Разработка и реализация требований
Когда требования прошли валидацию у стейкхолдеров, можно приступать к разработке ПО (т. е., к реализации этих требований).
Основной интерес вашей организации — получить прибыль от программного решения. Ваша задача и ответственность — попытаться использовать методы, снижающие стоимость разработки и поддержки.
Сделать это можно, например, путем повторного использования компонентов (внутри одной программы или из других продуктов), применения выверенных шаблонов и работы с проверенными инструментами (фреймворками) с хорошей документацией.
Специфические требования, в частности, ограничительные, могут очень сильно влиять на стоимость программ. Например, если ваш набор навыков не соответствует проекту или требования противоречат существующей архитектуре (или даже просто недостаточно хорошо в нее вписываются). Команда, занимающаяся проектом, должна найти возможные компромиссы, касающиеся таких требований.
Работая над проектом, вы должны понимать и даже ожидать, что довольно значительная часть требований изменится. Вам нужно научиться распознавать, где именно изменения будут неизбежны, и стараться проектировать программу таким образом, чтобы в нее можно было внести эти изменения.
User Story
Разработчик часто работает в контексте данной ему пользовательской истории (user story).
User story — это изложенное простыми словами представление о взаимодействии пользователя определенного типа с программным обеспечением и его функционалом. Обычно user story излагается в следующем формате:
Как я хочу , чтобы .
Как администратор курса я хочу видеть число записавшихся людей, чтобы оценивать наполненность курса.
В некоторых случаях user story поступает вместе с дизайном или прототипом — если это требовалось на стадии валидации.
User story не обязательно ориентирована на пользователя. Она может происходить из какой-то необходимости или нефункционального требования. В этих случаях вы можете получить требование в спецификации или наборе сценариев.
Каждая отдельная пользовательская история должна содержать минимально необходимое количество информации, позволяющее оценить, сколько усилий потребуется для ее реализации. Если команда не может сделать разумных прикидок, это может быть признаком того, что знания и навыки членов команды не подходят для проекта, у людей нет достаточной уверенности в своем уровне, существуют какие-то ограничения или, наконец, что сама user story низкого качества.
Разработчиков ограничивают (вынужденно) планы менеджмента проекта, но нужно стремиться обеспечивать качество на максимально высоком уровне с учетом доступных ресурсов.
Прежде, чем браться за реализацию user story, проверьте:
- что у вас есть подходящие критерии приемки, написанные стейкхолдерами или согласованные с ними. Эти критерии определяют, каким образом реализация в коде должна помочь пользователю достигнуть цели, заявленной в истории. Критерии приемки будут составлять основу приемочного тестирования (другими словами, тесты будут проверять, соответствует для функционал требованиям). Кроме того, с помощью этих критериев сама команда сможет определять, когда работа над функцией завершена.
- что дизайн прототипа (если вы его делали) в принципе можно реализовать, что это будет вписываться в существующую архитектуру, а также — что навыки разработчиков и имеющиеся у них инструменты позволяют выполнить эту работу.
- любые предположения относительно того, что стоит за требованиями. Таким образом вы сможете заполнить пробелы в знаниях, узнать о потенциальных проблемах, а также о неучтенных сценариях (edge cases), которые придется обсудить со стейкхолдерами.
«Торги» по требованиям к ПО
При реализации требований может оказаться, что вы не способны полностью удовлетворить интересы каждого стейкхолдера. Например, могут возникнуть разногласия между функциональными и нефункциональными требованиями или реализация одного требования может задевать какие-то другие интересы стейкхолдеров.
В таких случаях будет неразумно принимать решения в одностороннем порядке.
Вы должны донести информацию о возникших затруднениях до заинтересованных сторон. При этом надо простым языком рассказать о возможных компромиссах и согласовать их со стейкхолдерами (не выходя при этом за рамки бюджетных, технических, нормативных и прочих ограничений).
Верификация требований к ПО
Реализация любых требований должна проверяться. Это должно делаться как на уровне отдельных функций, так и на глобальном уровне (когда дело касается, например, нефункциональных требований). В общем, мы проверяем, насколько созданное ПО соответствует заявленным требованиям.
Спланировать, как будет верифицироваться каждое требование, это одна из важных задач.
Разработчики верифицируют требования при помощи приемочного тестирования. Эти тесты демонстрируют, насколько полно были выполнены требования. Делается это путем показа, что конечный пользователь может использовать созданное ПО в предусмотренных сценариях.
В случаях, когда продемонстрировать верификацию сложнее, например, когда речь идет о нефункциональных требованиях, может понадобиться некое моделирование. Скажем, чтобы протестировать производительность, может создаваться специальное ПО, симулирующее сотни или тысячи запросов к системе.
По мере развития программного обеспечения реализация каждого нового требования может непреднамеренно влиять на ранее реализованные требования. Это можно обойти, автоматизировав приемочные тесты. Для этой цели существует множество инструментов и библиотек.
Не следует считать приемочное тестирование единственно важным. Не забывайте покрывать свой код и другими тестами (например, модульные и интеграционными).
Приемочные тесты различаются по уровню сложности, который зависит от критериев приемки. Также в разных компаниях могут использовать разную терминологию и разные методы, из-за чего приемочное тестирование можно спутать со сквозным, функциональным или тестированием сценариев.
Помните, что суть каждого приемочного теста — просто формальная проверка того, что реализованное решение удовлетворяет требованиям, которые выдвигались к программному обеспечению. Делается это путем копирования поведения пользователей при запуске приложения.
Источник: techrocks.ru
5. Формирование требований к программному продукту.
Документ, в котором записываются сформулированные требования к программному средству, называется внешним описанием или спецификацией программного средства. В ней указывается, какие задачи должен выполнить разработчик и как оценить их достижение.
Внешнее описание играет роль точной постановки задачи и должно содержать всю информацию, необходимую пользователю для применения программного средства. Оно является исходным документом для 3-х параллельно протекающих процессов: — для разработки текстов программ (конструирование и кодирование). — разработки документации по применению ПС. — разработка существенной части комплекта тестов для тестирования ПС.
Исходным документом для разработки внешнего описания является определение требований к ПС, документ издается на основе общения с заказчиком. В спецификации выделяют 2 части: 1. Функциональная спецификация, описывающая функции программы. 2. Спецификация качества.
Описывает скорость работы программы, используемые ресурсы, требования к надежности и безопасности, требования к технологическим процессам (четкая формулировка). Внешнее описание ПС = определение требований + спецификация качества + функциональная спецификация. 3 уровня формализации спецификации: 1. словесная спецификация.
2. модельные и структурированные спецификации (построение схем, диаграмм и др.). 3. формальная спецификация (на основе математических формализмов). По способу представления спецификации выделяют: 1. Спецификации, имеющие текстовое представление (текстовые и формальные); 2. Представление с помощью информационных объектов (модельные).
4. Определение требований к пс.
- Управляемая пользователем разработка. Требования определяются заказчиком, когда заключает договор с коллективом разработчиков. В этом случае разработчик должен выяснить: понятны ему требования заказчика или нет.
- Контролируемая пользователем разработка. Требования формируются разработчиком при участии представителя пользователя. Пользователь информирует разработчика о своих потребностях и контролирует, насколько сформулированные требования отражают потребности (утверждается представителем пользователя).
- Независимая от пользователя разработка (при перспективе широкого применения разработанного ПС).
Наиболее предпочтителен вариант 2.
Проектирование (разработка архитектуры пс)
Результатом анализа требований и проектирования ПП должен стать проект, дающий четкое представление о системе и предназначенный для формирования на его основе программного кода.
Проектирование выполняется на 2 – х уровнях:
- Проектирование архитектуры ПС в целом (проектирование «в большом»).
- Детальное проектирование – проектирование модулей (проектирование «в малом»).
Под архитектурой понимают организацию программной системы, выбор структурных элементов, ее составляющих, и их интерфейсов.
Основные задачи разработки архитектуры ПС:
- Выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании).
- Определение способов взаимодействия между выделенными программными подсистемами.
В совокупности программную архитектуру описывают 4 структуры:
- Логическая – включает множество абстракций, необходимых для описания функциональных требований к системе на абстрактном уровне. Не затрагивает реализацию. Строится на основе анализа предметной области.
- Модульная – определяет организацию ПС как совокупности модулей, т. е. программных единиц, выполняемых членами команды разработчиков.
- Процессная – описывает поведение системы во время выполнения программы.
- Физическая – определяет отображение элементов ПС на аппаратное обеспечение.
Также используют другие структуры: структура вызовов, структура потоков, данных, структура потоков управления, структура классов.
Источник: studfile.net