Файл: Играсимулятор иткомпании по дисциплине.docx

Скачать файл
Заказать решение

ВУЗ: Не указан

Категория: Отчет по практике

Дисциплина: Не указана

Добавлен: 09.11.2023

Просмотров: 40

Скачиваний: 1

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Содержание

Команда

Заключение

Библиографический список

ПРИЛОЖЕНИЕ А



  1. Требования к продукту и к MVP


Требования систематизируются несколькими способами.

Требования клиентов

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

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

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

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

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

Производные требования

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

Например

Анкета должна содержать файл с фото, так как фото необходимо при оформлении документов – это бизнес-требование. А возможно, и бизнес-правило.

Из бизнес-требования следует, что у пользователя должна быть возможность прикрепить фото к анкете – это пользовательское требование. То есть требование, описывающее действия пользователя.

Получается, что система должна иметь функционал прикрепления фото к анкете – это уже функциональное требование, описывающее поведение системы. Или как должна работать система, чтобы выполнять исходное пользовательское требование.

Будем хранить все фото в формате base64 в отдельной таблице в БД – это нефункциональные требования.

Фото в очень хорошем качестве нам не нужно, а также мы не хотим покупать много памяти для сервера. Поэтому сделаем ограничение на размер загружаемого фото: не более 10 Мб.

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


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

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

  1. Стек для разработки


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

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

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

Не нужно ограничивать себя и все делать на одной технологии и только одном, ЛУЧШЕМ, языке программирования – огнестрел в руках ребенка эффективнее изучения боевых искусств самураем всю сознательную и бессознательную жизнь. Перфекционизм и идеализация убивают программные системы. Выбирайте верное оружие для каждой задачи в проекте. Берите готовое и сосредоточьте оставшиеся усилия на нестандартном.

Выбранные технологии должны быть простыми, понятными и доступными большинству в команде. Посмотрите, на чем пишут подобный проект в основном и возьмите этот стек технологий себе. Не автоматизируйте хостинг хаскелем и не пишите веб-сайты на C++ . Если ваш проект «взлетит» и начнет развиваться, только тогда можно рассмотреть возможность переписывания его небольших частей на более сложных технологиях и языках программирования. Но обычно до этой стадии программные проекты либо не доходят, либо доходят через несколько лет.

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

Технология и язык(и) программирования не являются определяющими факторами успеха. Сосредоточьтесь на выстраивании самых необходимых процессов и внедрении ключевых практик разработки и проектирования. Правильные процессы, как правило, гарантированно приводят к «правильному» результату. Связавшись с «сектантами чистой технологии» или «попав на науку», вы потратите кучу времени впустую и можете так ничего и не запустить. Помните, 2-3 месяца это максимум для запуска в бой очередной итерации программного проекта.

  1. Прототипирование


Процесс создания прототипа состоит из четырёх шагов:

  • определение начальных требований;

  • разработки первого варианта прототипа (в ПО. например, который содержит только пользовательский интерфейс системы);

  • этап изучения прототипа заказчиком и конечным пользователем. Получение обратной связи о необходимых изменениях и дополнениях;

  • переработка прототипа с учетом полученных замечаний и предложений.

Качества, которыми должен обладать эффективный прототип

Этап создания прототипа не должен быть затяжным.

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

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

Необходимо обращать внимание на элементы взаимодействия, которые принесут пользу вашему продукту.

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

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


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

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

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

Прототипы интерфейсов возможно привести в приложении к отчету.

  1. Разработка системы


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

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

Также на этом этапе можно привести схему взаимодействия программных модулей, т.е. схема потоков данных программы.

В этой части можно привести описание самого процесса разработки разнотипных сложных блоков программного обеспечения.



Заключение


Заключение должно содержать общие выводы, обобщенное изложение основных проблем. Могут быть указаны положительные и отрицательные стороны разработанного решения. Должны быть указаны перспективы дальнейшей разработки темы. Примерный объем заключения 2-3 страницы.

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

На данный момент сервис готовится к запуску и тестированию на реальных пользователях.

Библиографический список


  1. Веб-технологии для разработчиков Обзор протокола HTTP / Веб-технологии для разработчиков. – 2022. – URL: https://developer.mozilla.org/ru/docs/Web/HTTP/Overview (дата обращения: 30.04.2022).

  2. Вигерс К. Разработка требований к программному обеспечению / К. Вигерс, Дж. Битти. – 3-е изд. – Москва: Русская редакция, 2014. – 736 с. – ISBN 978-5-9909805-3-2.

  3. Евлантьев С.Карта эмпатии клиента / Станислав Евлантьев. – 2022. – URL: https://in-scale.ru/blog/karta-empatii/ (дата обращения: 01.05.2022).

  4. Ильяхов М. Пиши, сокращай: как создать сильный текст / М. Ильяхов, Л. Сарычева. – 3-е изд. – Москва: Альпина Паблишер, 2022. – 440 с. – ISBN 978-5-9614-6526-6.

  5. Кинзябулатов Р. IDEF0. Знакомство с нотацией и пример использования / Рамиль Кинзябулатов. – 2022. – URL: https://trinion.org/blog/idef0-znakomstvo-s-notaciey-i-primer-ispolzovaniya (дата обращения: 30.04.2022).

  6. Коберн А. Современные методы описания функциональных требований к системам / А. Коберн. – Москва: Издательство «Лори», 2012. – 264 с. – ISBN 978-5-85582-326-4.

  7. Мидоус Ф. Введение в протоколы HTTP и HTTPS / Филлип Мидоус. – 2022. – URL: https://docs.microsoft.com/ru-ru/azure/rtos/netx-duo/netx-duo-web-http/chapter1 (дата обращения: 05.05.2022).

  8. Сырцев В. Использования диаграммы вариантов использования UML при проектировании программного обеспечения / Вадим Сырцев. – 2021. – URL: https://habr.com/ru/post/566218/ (дата обращения:30.04.2022).

  9. Фирстов Л. О развитии навыка говорения / Леонид Фирстов. – 2020. – URL: https://habr.com/ru/post/494424/ (дата обращения: 30.04.2022).

  10. Фитцпатрик Р. Спроси маму: Как общаться с клиентами и подтвердить и подтвердить правоту своей бизнес-идеи, если все кругом врут? / Р. Фитцпатрик. – Москва : Альпина Паблишер, 2021. – 160 с. – ISBN 978-5-9614-3045-5.

  11. Шейнблат В. Естественный подход к освоению языка / Владимир Шейнблат. – 2022. – URL: https://englishsimple.ru/articles/natural-approach-to-language-learning/ (дата обращения: 25.04.2022).

  12. Шторкин С. Средневзвешенная система голосования / Семен Шторкин – 2022. – URL: https://habr.com/ru/post/63664/ (дата обращения: 30.04.2022).

  13. Apple MacOS / Apple. – 2022. – URL: https://www.apple.com/za/macos/what-is/ (дата обращения: 30.04.2022).

  14. Best Programmer Функциональные и нефункциональные требования: полное руководство / Best Programmer. – 2021. – URL: https://bestprogrammer.ru/izuchenie/funktsionalnye-i-nefunktsionalnye-trebovaniya-polnoe-rukovodstvo (дата обращения: 15.05.2022).

  15. Google Chrome Браузер от Google / Google Chrome. – 2022. – URL: https://www.google.ru/chrome/ (дата обращения: 30.04.2022).

  16. HeyLady Женское сообщество для создания конференций и практики английского языка / HeyLady. – 2022. – URL: https://www.heylady.io/ (дата обращения: 30.04.2022).

  17. Lingbe Бесплатные звонки с носителями в любое время / Lingbe. – 2022. – URL: https://lingbe.com/ (дата обращения: 30.04.2022).

  18. PostgrePro Что такое PostgreSQL? / PostgrePro. – 2020. – URL: https://postgrespro.ru/docs/postgresql/12/intro-whatis (дата обращения: 30.04.2022).

  19. Proglib Об Agile / Denver. – 2022. – URL: https://proglib.io/p/klyuchevye-razlichiya-mezhdu-agile-scrum-i-kanban-2022-02-24 (дата обращения 05.04.2022).

  20. SimilarWeb Аналитика трафика Tandem / SimilarWeb. – 2022. – URL: https://www.similarweb.com/ru/website/tandem.net/#traffic (дата обращения: 30.04.2022).

  21. Tandem / Tandem.net. – 2022. – URL: https://www.tandem.net/ru (дата обращения: 30.04.2022).

  22. JavaScript WebSocket / JavaScript. – 2022. – URL: https://learn.javascript.ru/websocket (дата обращения: 02.05.2022).

  23. VC.RU Анализ конкурентов на практике / VC.RU. – 2020. – URL: https://vc.ru/marketing/181297-analiz-konkurentov-na-praktike-10-shagov-shablon (дата обращения: 30.04.2022).

  24. VC.RU Как составить портрет клиента (целевой аудитории) / VC.RU. – 2020. – URL: https://vc.ru/marketing/156147-kak-sostavit-portret-klienta-celevoy-auditorii-instrukciya-s-primerami (дата обращения: 30.04.2022).

Смотрите также файлы