Файл: Классификация требований к по. 9 Валидация требований 10.docx
Добавлен: 27.10.2023
Просмотров: 102
Скачиваний: 1
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Сделать это можно, например, путем повторного использования компонентов (внутри одной программы или из других продуктов), применения выверенных шаблонов и работы с проверенными инструментами (фреймворками) с хорошей документацией.
Специфические требования, в частности, ограничительные, могут очень сильно влиять на стоимость программ. Например, если ваш набор навыков не соответствует проекту или требования противоречат существующей архитектуре (или даже просто недостаточно хорошо в нее вписываются). Команда, занимающаяся проектом, должна найти возможные компромиссы, касающиеся таких требований.
Работая над проектом, вы должны понимать и даже ожидать, что довольно значительная часть требований изменится. Вам нужно научиться распознавать, где именно изменения будут неизбежны, и стараться проектировать программу таким образом, чтобы в нее можно было внести эти изменения.
Верификация требований к ПО
Реализация любых требований должна проверяться. Это должно делаться как на уровне отдельных функций, так и на глобальном уровне (когда дело касается, например, нефункциональных требований). В общем, мы проверяем, насколько созданное ПО соответствует заявленным требованиям.
Спланировать, как будет верифицироваться каждое требование, это одна из важных задач.
Разработчики верифицируют требования при помощи приемочного тестирования. Эти тесты демонстрируют, насколько полно были выполнены требования. Делается это путем показа, что конечный пользователь может использовать созданное ПО в предусмотренных сценариях.
В случаях, когда продемонстрировать верификацию сложнее, например, когда речь идет о нефункциональных требованиях, может понадобиться некое моделирование. Скажем, чтобы протестировать производительность, может создаваться специальное ПО, симулирующее сотни или тысячи запросов к системе.
По мере развития программного обеспечения реализация каждого нового требования может непреднамеренно влиять на ранее реализованные требования. Это можно обойти, автоматизировав приемочные тесты. Для этой цели существует множество инструментов и библиотек.
Не следует считать приемочное тестирование единственно важным. Не забывайте покрывать свой код и другими тестами (например, модульные и интеграционными).
Приемочные тесты различаются по уровню сложности, который зависит от критериев приемки. Также в разных компаниях могут использовать разную терминологию и разные методы, из-за чего приемочное тестирование можно спутать со сквозным, функциональным или тестированием сценариев.
Помните, что суть каждого приемочного теста — просто формальная проверка того, что реализованное решение удовлетворяет требованиям, которые выдвигались к программному обеспечению. Делается это путем копирования поведения пользователей при запуске приложения.
5 Порядок ревьюирования программных продуктов на предприятии.
Системы контроля версий
Система контроля версий является прежде всего инструментам, а инструмент призван решать некоторый класс задач. Итак, система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы хотим гибко управлять некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть кто что-то поменял. Как правило системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа.
Как хранить различные версии файлов? Люди пришли к такому инструменту как системы контроля версий не сразу, да и они сами бывают очень разные. Предложенную задачу можно решить с применением старого доброго copy-paste, локальных, централизованных или распределенных систем контроля версий.
Copy-paste
Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_{version}, возможно с добавлением времени создания или изменения.
Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).
Локальная система контроля версий
Следующим шагом в развитии систем контроля версий было создание локальных систем контроля версий. Они представляли из себя простейшую базу данных, которая хранит записи обо всех изменениях в файлах.
Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux'ом.
Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство — локальность. Она совершенно не преднезначена для коллективного использования.
Централизованная система контроля версий
Централизованная система контроля версий предназначена для решения основной проблемы локальной системы контроля версий.
Для организации такой системы контроля версий используется единственный сервер, который содержит все версии файлов. Клиенты, обращаясь к этому серверу, получают из этого централизованного хранилища. Применение централизованных систем контроля версий на протяжении многих лет являлась стандартом. К ним относятся CVS, Subversion, Perforce.
Такими системами легко управлять из-за наличия единственного сервера. Но при этом наличие централизованного сервера приводит к возникновению единой точки отказа в виде этого самого сервера. В случае отключения этого сервера разработчики не смогут выкачивать файлы. Самым худшим сценарием является физическое уничтожение сервера (или вылет жесткого диска), он приводит к потерю кодовой базы.
Несмотря на то, что мода на SVN прошла, иногда наблюдается обратный ход — переход от Git'а к SVN'у. Дело в том, что SVN позволяет осуществлять селективный чекаут, который подразумевает выкачку лишь некоторых файлов с сервера. Такой подход приобретает популярность при использовании монорепозиториях, о которых можно будет поговорить позже.
Распределенная система контроля версий
Для устранения единой точки отказа используются распределенные системы контроля версий. Они подразумевают, что клиент выкачает себе весь репозиторий целиком заместо выкачки конкретных интересующих клиента файлов. Если умрет любая копия репозитория, то это не приведет к потере кодовой базы, поскольку она может быть восстановлена с компьютера любого разработчика. Каждая копия является полным бэкапом данных.
Все копии являются равноправным и могут синхронизироваться между собой. Подобный подход очень напоминает (да и является) репликацией вида master-master.
К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.
Распределенная система контроля версий
Для устранения единой точки отказа используются распределенные системы контроля версий. Они подразумевают, что клиент выкачает себе весь репозиторий целиком заместо выкачки конкретных интересующих клиента файлов. Если умрет любая копия репозитория, то это не приведет к потере кодовой базы, поскольку она может быть восстановлена с компьютера любого разработчика. Каждая копия является полным бэкапом данных.
Заключение
С 18 мая по 21 июня 2023 года я прошел учебную и производственную практику в АО «ФНПЦ «ПО «Старт» им. М.В. Проценко», г. Заречный.
В результате прохождения практики на предприятии я получил практический опыт:
интеграции модулей в программное обеспечение;
отладке программных модулей;
измерении характеристик программного проекта;
использовании основных методологий процессов разработки программного обеспечения;
оптимизации программного кода с использованием специализированных программных средств.
Считаю, что задачи, поставленные передо мной в начале практики, были выполнены. Цель практики достигнута.
Список используемой литературы
-
Гниденко, И. Г. Технология разработки программного обеспечения: учебное пособие для среднего профессионального образования / И. Г. Гниденко, Ф. Ф. Павлов, Д. Ю. Федоров. — Москва: Издательство Юрайт, 2023. — 235 с. — (Профессиональное образование). — ISBN 978-5-534-05047-9. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/472502. -
Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для среднего профессионального образования / Е. А. Черткова. — 2-е изд., испр. и доп. — Москва: Издательство Юрайт, 2023. — 147 с. — (Профессиональное образование). — ISBN 978-5-534-09823-5. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/473307. -
Грекул, В. И. Проектирование информационных систем: учебник и практикум для среднего профессионального образования / В. И. Грекул, Н. Л. Коровкина, Г. А. Левочкина. — Москва: Издательство Юрайт, 2023. — 385 с. — (Профессиональное образование). — ISBN 978-5-534-12104-9. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/476534. -
Проектирование информационных систем: учебник и практикум для среднего профессионального образования / Д. В. Чистов, П. П. Мельников, А. В. Золотарюк, Н. Б. Ничепорук; под общей редакцией Д. В. Чистова. — Москва: Издательство Юрайт, 2023. — 258 с. — (Профессиональное образование). — ISBN 978-5-534-03173-7. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/471492. -
Григорьев, М. В. Проектирование информационных систем: учебное пособие для среднего профессионального образования / М. В. Григорьев, И. И. Григорьева. — Москва: Издательство Юрайт, 2023. — 318 с. — (Профессиональное образование). — ISBN 978-5-534-12105-6. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/476536. -
Древс, Ю. Г. Имитационное моделирование: учебное пособие для среднего профессионального образования / Ю. Г. Древс, В. В. Золотарёв. — 2-е изд., испр. и доп. — Москва: Издательство Юрайт, 2023. — 142 с. — (Профессиональное образование). — ISBN 978-5-534-11951-0. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/475680. -
Боев, В. Д. Компьютерное моделирование систем: учебное пособие для среднего профессионального образования / В. Д. Боев. — Москва: Издательство Юрайт, 2023. — 253 с. — (Профессиональное образование). — ISBN 978-5-534-10710-4. — Текст: электронный // ЭБС Юрайт [сайт]. — URL: https://urait.ru/bcode/473033.