Создание программного продукта

Создание программного продукта

http://lelina.tilda.ws/it_development

Четыре фазы разработки ПО

• 1. Спецификация (ТЗ) и архитектура
• 2. Реализация
• 3. Тестирование и документирование
• 4. Внедрение и техническая поддержка

• 1. Спецификация (ТЗ) и архитектура: разработка функциональных требований к ПО (технического задания) [аналитик];
• разработка архитектуры системы [инженер-архитектор]
• 2. Реализация: разработка структуры базы данных (далее - БД) [программист] ;
• кодирование: разработка программной логики, функций, интерфейса [программист];
• интеграция с другими информационными системами (при необходимости) [программист]

• 3. Тестирование и документирование: разработка сценариев тестирования [программист/тестировщик];
• разработка автотестов [QA программист];
• функциональное (ручное) тестирование [тестировщик];
• разработка технической документации [программист];
• разработка пользовательской документации [технический писатель]
• 4. Внедрение и техническая поддержка: внедрение, обучение пользователей, сбор замечаний и ошибок [аналитик-консультант];
• техническая поддержка (сбор замечаний, исправление ошибок, консультирование пользователей) [специалист]

Классическая схема

цикла разработки ПО

Разработка требований к ПО

Бизнес-требования  (business requirements) содержат высокоуровневые цели организации или заказчиков системы ... оформляются в форме документа об образе и границах проекта, который еще иногда называют уставом проекта Требования пользователей  (user requirements) описывают цели и задачи, которые пользователям позволит решить система. Функциональные требования  (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Функциональные требования документируются в спецификации требований к ПО (software requirements specification, SRS), где описывается так полно, как необходимо, ожидаемое поведение системы. Характеристика  (feature) — это набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.

Основными проблемами данного этапа являются:

• недостаточное вовлечение пользователей;
• «разрастание» требований пользователей;
• неоднозначность требований (разные трактовки и восприятия);
• добавление функций, которых нет в спецификации;
• минимальная спецификация (в итоге Заказчик получит не тот продукт, который ожидал);
• не полный охват всех классов пользователей (не будут учтены все необходимые функциональные возможности).

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

• Для продукта, который будет использоваться  внешними пользователями , необходимо собрать их пожелания и предложения к продукту. Это достаточно сложный процесс. Получить информацию от внешних клиентов возможно при личном контакте (общении), с помощью формы обратной связи «Ваши предложения», при проведении анкетирования (опроса). Онлайн опрос возможно оформить, например, с помощью таких приложений, как  surveymonkey ,  survio  и др.

• Оформление требований  в виде документа зависит от целей и масштаба проекта. Рассмотрим некоторые приемы, применяемые для документирования функциональных требований к программным системам: 1) разработка в соответствии с  ГОСТами серии 19 и 34 . ГОСТы предоставляют четкую структуру разрабатываемой документации, обладают свойствами полноты и непротиворечивости, а также снимают спорные вопросы между исполнителем и заказчиком к результатам работ.  Ограничения: - сложность разработки, согласования и дальнейшей поддержки - жесткие требования к детализации

• 2)  пользовательские истории  (англ.  User Story ) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном языке пользователя. Применяется в Scrum методологии как быстрый способ документирования требований клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Ограничения: - отсутствие деталей, что ведет к различным интерпретациям - могут плохо масштабироваться на больших проектах - требуется большая компетенция от разработчика - не учитывают полного бизнес-процесса и, как результат, в итоге могут оказаться ошибочными из-за отсутствия всестороннего исследования предметной области.

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

• 4)  прецедент  (англ.  Use Case ) - спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в Унифицированном языке моделирования (UML), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними действующими лицами (англ.  Actors ). 5)  спецификация требований  программного обеспечения (англ.  Software Requirements Specification, SRS ) является полным описанием поведения системы, которая будет создана, а также нефункциональные требования в виде дополнительных ограничений (требования к эффективности, безопасности и др.). 

• 6)  дизайн продукта  - разработка пользовательских интерфейсов. Выделяют UX и UI дизайны. Простыми словами: UX делает интерфейсы полезными, а UI делает интерфейсы красивыми. 

• По словам дизайнера Ника Бабича: " UX дизайнер, скорее будет разрабатывать потоки пользователей, шаги, которые пользователь предпримет, чтобы, например, подписаться на рассылку. Каким шагам они будут следовать и как они поймут, что всё удалось? Затем проект переходит UI дизайнеру. UI дизайнер усовершенствует эти взаимодействия добавляя цвет и подчеркивая оригинальный дизайн, давая им подсказки, и показывая направление к новостной рассылке."

Список литературы:

• https://it.rfei.ru/course/~jRzS/~PzPM
• http://lelina.tilda.ws/it_development
• https://www.edsd.ru/ru/princypy/cikl_razrabotki_po
• https://experrto.io/articles/~startap-s-nulia-luchshiie-biznies-modieli~4109/
• http://lelina.tilda.ws/it_development