Страница 5 из 10
Страница 5 из 10
Педагогическая наука и практика как единая система
Потребность передавать опыт от поколения к поколению появилась, наряду с другими потребностями человека, на самом раннем этапе возникновения общества. Поэтому практика воспитания первоначально определялась как передача жизненного опыта человека от старшего поколения к младшему. Воспитание было таким же общественным явлением, как и любая деятельность человека: охота, собирательство, изготовление орудий труда. Человек рос как личность, усложнялся его социальный опыт, и вместе с ним, усложнялись процесс и цели воспитания.
До того как зародилась письменность, суждения о воспитании имели устное бытование и до нашего времени дошли в виде пословиц, поговорок, афоризмов, крылатых выражений. Истоки народной педагогики, как первого этапа развития педагогики вообще, мы находим в сказках, былинах, песнях, частушках, детских прибаутках, пословицах, поговорках, заговорах, колыбельных песнях и песнях-хороводах, загадках, скороговорках, считалках, оглядках, исторических преданиях, народных приметах. Так, например, известно множество русских пословиц и поговорок, имеющих педагогическое назначение: «Не везде сила — где уменье, а где — и терпенье», «Чего в другом не любишь, того и сам не делай», «С кем хлеб-соль водишь, на того и походишь», «Доброе братство сильнее богатства», «Природу не надо увечь, а надо беречь», «Корень учения горек, да плод сладок», «Наука не пиво, в рот не вольёшь», «Повторение — мать учения», «От умного научишься, от глупого разучишься», «Век живи — век учись», «Учение — красота, а неучение — сухота». Издавна был ясен многоплановый характер пестушек — магический заговор на здоровье ребенка (из язычества), развитие слуха, эстетического чувства и способа общения, настрой на гармоничный музыкально-поэтический лад. Пестушка пробуждала чувство ритма, желание двигаться, слушать и говорить.
Интерес представляют разные институты воспитания и обучения, существовавшие в тот период на Руси. Например, «кормильство» — своеобразная форма домашнего воспитания детей феодальной знати. В возрасте 5-7 лет малолетний княжич отдавался кормильцу, которого князь подбирал из числа воевод, знатных бояр. При этом кормилец выполнял несколько функций. Он был не только наставником-воспитателем, но и распоряжался делами в порученной ему отдельной волости от имени воспитанника. В обязанности кормильца как наставника входило умственное, нравственное и военно-физическое воспитание, раннее привлечение княжича к государственным делам. Другой институт воспитания и обучения в Древней Руси — «дядьки». Дети воспитывались у брата матери, то есть у родного дяди. В свою очередь отец ребенка принимал на воспитание детей родной сестры. В результате создавались оригинальные семьи, в которых «дядьки» воспитывали племянников и племянниц. «Дядьки» были наставниками племянников, а те — первыми их помощниками. Институт «кумовства» — трансформация «дядьки» из воспитателя племянников в своей семье в духовного и нравственного наставника детей в семье родителей. С принятием христианства «кум» и «кума» стали крестными отцом и матерью.
Позже появились институт «мастеров грамоты» — одиночек и школы «мастеров грамоты». Мастера грамоты были главными лицами народного просвещения и подготовки духовенства, сделавшие промысел из обучения грамоте. Как правило, они основывали школы: в семье, в домах учителей, при монастырях и церквях. Обучение детей было тяжелым делом, требовавшим времени и великой затраты сил, чтобы научить немногому — читать и писать. История развития русского педагогического самосознания по П. Ф. Каптереву, выдающемуся русскому педагогу конца XIX и начала XX века, проходит три периода: церковный, государственный и общественный.
Истоки педагогической мысли как отражение практики обучения и воспитания обнаруживают у различных народов, прежде всего в древних памятниках письменности. Например, в таких произведениях древнерусской литературы, как «Слово о пользе учения», «Поучение князя Владимира Мономаха детям», «Сборник афоризмов «Пчела»», «Послание» Климента Смолятича, «Слово о законе и благодати», «Повесть об Акире Премудром» — можно почерпнуть знания об особенностях образования и воспитания просвещенной Древней Руси X-XIII веков. Богата традициями русская педагогическая мысль.
Лишь в 16-17 веках педагогика становится самостоятельной наукой. Педагогика как наука сосредоточилась на проблемах:
· человек;
· личность и общество;
· воспитание, образование, обучение;
· идеалы воспитания;
· идеал личности в обществе.
Педагогика становится наукой об образовании, процессе просвещения и самовоспитания личности. Наука — сфера человеческой деятельности, результатом которой являются новые знания.
Источники развития педагогики как науки
1. Опыт и традиция народного воспитания (в настоящее время – этнопедагогика).
2. Философские, обществоведческие, педагогические и психологические труды выдающихся ученых.
3. Текущая мировая и отечественная практика воспитания.
4. Данные специально организованных социологических и педагогических исследований.
5. До середины 80-х – опыт педагогов – новаторов, с середины 80х годов –экспериментальные площадки, в настоящее время – инновационные технологии.
Анализ
last update: 04-09-2021, 20:57 UTC
Почерпнуть мудрость
Фундамент — литература
- (PDF) Разработка требований к ПО (Карл Вигерс, 2014)
Фундаментальный труд, очень объёмный, читать выборочно. В бумаге продаётся издание 2018 года. - (PDF) Сжатая выборка основных мыслей из книги 2016 года издания «Принципы работы с требованиями к программному обеспечению. Унифицированный подход» Дина Леффингуэлла
- (PDF) Разработка и управление требованиями. Практическое руководство пользователя. (Telelogic, 2005)
- (PDF) Современные методы описания функциональных требований к системам. (Алистер Коберн, 2002). Советую издание посвежее.
Стандарты
- (PDF) ISO 29148-2018. Systems and software engineering — Life cycle processes — Requirements engineering
- (PDF) BABOK version 3 (2015)
- «Мякотка» из BABOK в веб-формате. Всё удобно, но отсутствуют схемы и имеются опечатки.
Видео
- Как организовать требования: порядок бьет класс (Алексей Пименов, 2020). О уровнях зрелости требований
- Неявные особенности работы BI BA (Ксения Калашникова, 2020)
Статьи
- Судьба требований ГОСТ 34 серии в проектах информационной безопасности
- Единственный контекст потребителя (Тихомиров Сергей, 2020). Отличная статья о формировании гипотез поведения/проблемы/мотивации/блокеров для определении контекста, о популярных моделях, о составлении правильных вопросов для интервью, о формулировании и маппинге ценностных предложений на цели заказчика.
- A collection of practices and patterns to support software evolution, modernization, maintenance, migration and improvement of software systems. Своего рода свод знаний о паттернах анализа в контексте модернизации систем.
- Проектирование интеграции с веб-сервисом
Практика формирования требований в IT-проектах от А до Я.
- Часть 1. Вводная
- Часть 2. Цели и Потребности
- Часть 3. Функции системы и Границы проекта
- Часть 4. Бизнес процессы, автоматизируемые системой
- Часть 5. Сущности предметной области и немного о стратегиях
- Часть 6. Поведение системы. Совершенстваоние требований
- Часть 7. Передача требований в производство. Заключение
Пара определений
- Транзакция = способ группировки операций чтения/записи в одну логическую единицу, в рамках которой эти операции либо выполняются целиком либо не выполняются с их прерыванием и откатом.
ПО для Аналитика
- Для составления BPMN и UML:
- (бесплатное, требуется регистрация) storm.bpmn2.ru = онлайн-сервис для описания бизнес-процессов и инструкций в BPMN
- (бесплатное, требуется регистрация) diagrams.net (бывший draw.io) = онлайн-сервис для составления диаграмм UML, BPMN, Archimate и др.;
Можно скачать Desktop-приложения для - (условно—бесплатное) Modelio Open Source = десктоп-приложение UML, BPMN, ArchiMate, SysML. Есть платные плагины и модули.
Видеообзор работы в Modelio (15 минут)
- Для работы с Требованиями (разработка, управление, трассировка):
- (очень платное) IBM Rational DOORS
- (платное)(есть trial на 14 дней) Cradle
- (платное) DevProm Requirements. Один из функциональных блоков программного продукта Devprom ALM
- (платный) плагин RMsis для Atlassian JIRA
- (платный) плагин R4J для Atlassian JIRA
- Для работы и с Требованиями и с Архитектурой:
- (платный) Enterprise Architect (платный, есть trial на 30 дней) ( и могут установить EA под WINE). В высшей степени могущественный инструмент.
- (платное) SAP Power Designer.
- Для создания прототипов интерфейсов:
- (платное)(есть Starter — бесплатный режим) Figma
- (платное)(есть free trial на 30 дней) Axure RP
- Для совместной онлайн-работы с коллегами:
- (условно—бесплатное, требуется регистрация) Lucidchart = online collaborative diagrams. Есть фигуры из нотаций UML и BPMN.
- (условно—бесплатное, требуется регистрация) Miro = online collaboration whiteboard. Хорош для brainstorm, быстрых набросков.
Можно скачать Desktop- и мобильные приложения для различных платформ
Аналитики — кто?
Бизнес-аналитик
Основные решаемые задачи:
- определение ключевых заинтересованных лиц проекта (Stakeholders), ожидания которых должны быть удовлетворены;
- (совместно с Заказчиком) определение Бизнес-требований;
- определение Бизнес-ограничений, Требований государственных и международных регуляторов
- (совместно с Ключевым пользователем) выявление Пользовательских требований;
- (совместно с менеджером проекта) разработка концепции Проекта
- планирование работ с требованиями в рамках проекта (анализ, верификация, проверка качества)
- документирование Бизнес и Пользовательских требований
- Ведение репозитория требований
- (при необходимости) реверс-инжиниринг бизнес-процессов.
Основные создаваемые артефакты
- описание моделей бизнес-процессов As Is
- описание моделей бизнес-процессов To Be
- описание Бизнес- и Пользовательских требований
- обновления репозитория Требований
- создание Vision (Концепции проекта) / Рамок проекта / Соглашения о границах проекта
Системный аналитик
Специалист, который на основе Бизнес- и Пользовательских требований проектирует техническое решение и разрабатывает функциональные (какие функции должны быть релизованы в разрабатываемом ПО) и нефункциональные требования.
Основные решаемые задачи
- (совместно с Системным архитектором) определение границ Системы (разрабатываемого ПО) и контекста её работы
- анализ Бизнес-требований и Пользовательских требований, определение Ограничений
- участие в разработке Проектного решения
- декомпозиция Бизнес-сценариев на Системные сценарии
- создание сценариев использования (use case)
- разработка Функциональных и неФункциональных требований, реализующих Системные сценарии
- разработка Пользовательских требований в границах Системы
- документирование Требований
- Ведение репозитория требований
Основные создаваемые артефакты
- Техническое задание / Спецификация на изменение ПО (SRS)
- описание Проектного решения
- описание Пользовательских требований уровня Системы
- обновления репозитория Требований
Требования к системному аналитику: должен иметь хороший ИТ-бэкграунд, должен уметь свободно говорить на одном языке с разработчиками и с бизнес-пользователями.
Портрет аналитика
- (опционально) возможные занимаемые ранее позиции работы Бизнес-аналитиком / Системным аналитиком / UX-проектировщиком / Системным архитектором
- Коммуникативные навыки:
- Умение устанавливать контакт с незнакомыми людьми;
- Умение слушать собеседника и держать в голове цель переговоров;
- Навыки ведения переговоров с бизнес-заказчиком ИТ-доработок;
- Умение аргументированно отстаивать свою позицию;
- (опционально) навыки ведения презентаций.
- Системный анализ. Навыки определения контекста системы, анализа предметной области, структурной декомпозиции объектов предметной области.
- иметь представление о жизненном цикле ПО. Ориентация в ключевых методологиях разработки: Waterfall, RUP, Agile, Kanban, для гос. заказчиков — ГОСТ 19 и 34;
- навыки разработки моделей предметной области в нотациях Archimate, BPMN
- знание языка UML, умение разрабатывать диаграммы предметной области (use cases, activity, state, sequence diagrams)
- навыки работы с БД, знание SQL (PL-SQL), из нереляционных — MongoDB (негласный стандарт)
- знание технологий интеграции IT-систем (xsd, xml, wsdl, SOAP, REST). Навыки разработки технических заданий на интеграцию ИТ-систем. Желательно знакомство с понятием сервис-ориентированной архитектуры.
- владение векторными графическими редакторами типа Archi, Visio, diagrams.net, gliffy, Modelio;
- (опционально) навыки работы с системами управления требованиями (Rational RequisitePro, DOORS, Jira+ Confluence)
- (опционально) владение инструментами проектирования/моделирования, самое востребованное на рынке: Archi, Sparx Enterprise Architect и Rational Rose;
О документации
Кратко.
Не делайте документацию, которая вам не нужна.
Делать документацию стоит там, где уже есть проблемы или где это экономически оправдано.
Иначе, вместо работы мы будем заниматься раскладкой соломы во всех местах где можем подскользнуться.
Подробно.
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через N лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional).
Первая однозначно нужна в любом случае и должна быть всегда актуальной.
Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
core-документация:
- В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования ИС.
В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен. - Как только бизнес хочет начать работать по-другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем.
К этому привязываются изменения в функциональных модулях. - Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
Весь список «бумажек» нужный для разработки и доработки:
- Реестр ТЗ.
- Бизнес-часть ТЗ: описание бизнес-сценария и его системных сценариев использования.
Бизнес-сценарий и системные сценарии использования по сути и есть сценарии приёмо-сдаточных испытаний.
Это на 50% готовые приёмочные тесты. - Дополнение к бизнес-части ТЗ: указание что на что меняем в бизнес-сценарии и системных сценариях.
Как правило, после выполнения работ и подготовки обновленной версии ТЗ «выкидывается». - Техническая часть ТЗ: раскладка системных сценариев на сущности системы.
Критерии приёмки:
- соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
- отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Бизнес-процесс
Бизнес-процесс = совокупность взаимосвязанных мероприятий или работ, направленных на создание определённого Продукта/Услуги.
В качестве графического описания деятельности применяются нотации (блок-схемы) бизнес-процессов.
Виды Бизнес-процессов:
- Управляющие — управляют функционированием системы.
Примеры: Корпоративное управление и Стратегический менеджмент. - Операционные — составляют основной бизнес компании и создают основной поток доходов.
Примеры: Снабжение, Производство, Маркетинг, Продажи и Взыскание долгов. - Поддерживающие — обслуживают основной бизнес.
Примеры: Бухгалтерский учет, Подбор персонала, Техническая поддержка, административно-хозяйственный отдел.
Базовые процессы в компаниях
- Процесс обеспечения доступности товара.
Результат: появление Продукта, обеспечение возможности предоставления Услуги. - Процесс по организации сбытовой деятельности.
Результат: Продукт уходит Клиенту, оказание Услуги. - Процесс по управлению продуктами.
Результат: выпуск Продуктов и оказание Услуг, которые востребованы. - Процесс по управлению качеством.
Результат: отсутствие возврата Продукта от Клиента, жалоб на качество Услуг.
Источники информации о БП в компании
Часто приходится сталкиваться с тем, что бизнес-процессы в компании не описаны, либо описаны плохо, либо описание давно не актуально, неизвестно как конкретно и какие ИС задействованы в них и т.д.
Тогда аналитику для обретения понимания что происходит, кто и что задействовано — приходится заниматься обратной инженерией (реверс-инжиниринг, reverse engineering) бизнес-процессов.
Для этого необходимо обращаться к:
- регламентам
- должностным инструкциям
- корпоративным Базам Знаний
- людям — непосредственным исполнителям Ролей в БП
Разработка бизнес-процессов
В очень общем виде:
- Создание любого процесса начинается с указания цели, которую необходимо достигнуть этим процессом.
- Затем должно быть что получаем в него на вход, чего ожидаем на выходе.
- Только затем определяем исполнителей и их действия со взаимосвязями.
- Важно посчитать себестоимость исполнения экземпляра процесса.
Анализ бизнес-процессов
- убедиться, что работа не дублируется
- убедиться, что место работы и место принятия решения единственные (т.е. заявка и решение не курсируют по всему зданию, и чтобы купить стул вахтеру не нужна подпись гендира), и одинаковые задачи решаются одинаковым способом
- убедиться, что за контроль и исполнение отвечают разные люди, не связанные друг с другом
- убедиться, что за каждое движение и актив хоть кто-то отвечает, чтобы при успехе самый наглый не говорил «Я!», а при провале «Они!»
- обеспечить полную загрузку персонала, лишних сократить или отправить расширять бутылочное горлышко
- разобраться, какие процессы создают ценность, а какие ни денег не приносят, ни другим отделам не помогают, а «так исторически повелось»
- разобраться, какие процессы (например, часть информационных) можно переложить на автоматические системы
Оптимизация бизнес-процессов
- Минимизация участников БП
- Типизация БП
- Упрощение БП
- Сокращение времени протекания БП
- Обеспечение параллельности БП
- Исключение излишнего контроля в БП
- Минимизация участия руководства в БП
- Сокращение стоимости БП
- Реинжиниринг БП (фундаментальная реорганизация с целью повышения эффективности)
Требования
Требование (requirement) = утверждение (statement), которое выражает нужды (needs) и связанные с ними обстоятельства (conditions) и ограничения (constraints).
Атрибуты требования
Идентификатор, Имя, Требование, Приоритет, Причина приоритета, Статус, Источник и т.д.
Модель зрелости требований (RMM, requirements maturity model)
Ресурсы:
- (PDF) The Five Levels of Requirements Management Maturity (Rational Software, 2003)
- Как организовать требования: порядок бьет класс (Алексей Пименов, 2020). Что такое организация требований. Как готовить и хранить требования. Мастер-класс: как организовать свои требования за полчаса.
- Отсутствуют (Unwritten / Chaos)
- Не документируются
- Разработка решения идёт на основе предположений и интерпретаций
- Нет инструкций, процессов
- Нет общего однозначного опнимания о том, как должно работать решение
- Пишутся (Written)
- хранятся в востанавливаемом хранилище
- по-прежнему требования понимаются по-разному
- отражают текущее понимание решения
- есть Knowledge base
- Организованы (Organized)
- ведутся в едином синтаксисе, легкочитаемом и понятном формате (содержание, заголовки, шрифт)
- отвечают критериям качества
- внедрена ролевая модель доступа к требованиям
- версионируются
- Структурированы (Structured)
- имеют продуманную структуру, написаны по шаблонам, отвечающим потребностям вашего проекта/решения
- поделены по уровням (user, business, system,..) и типам (functional, non-functional,..)
- имеют полезные для вас атрибуты (ID, приоритет, источник, ссылки на связанные материалы,…)
- Прослеживаемы / трассируемы (Traced)
Т.е. уложены в таблицы трассировки или снабжены кросс-ссылками или имеют связи в системах управления требования на связанные и зависимые требования и другие сущности (архитектурные компоненты системы, бизнес-процессы, тест-кейсы, экранные формы).
В конечном счёте каждое бизнес- и пользовательское требование должно иметь связь с функциональным/нефункциональным. Если, например, у какого-либо бизнес-требования нет никаких связей с функциональными/нефункциональными требованиями, то, видимо, мы про него забыли и не придумали как его реализовать в продукте.
- Интегрированы (Integrated)
Интегрированы в систему управления требованиями или даже в код, т.е. настолько сильно сросшиеся с проектом/продуктом, что изменение требований чуть ли не сразу ведёт к изменению самого продукта.
Очень редко попадающийся уровень.
Модель процессов по работе с Требованиями
В самом общем виде:
(скачать модель в .archimate)
Уровни и типы требований
скачать схему в формате diagrams.net (бывший draw.io)
Бизнес-требования (business requirements) выражают цель, ради которой разрабатывается Продукт/Услуга (зачем вообще нужен, какая от него ожидается польза, как заказчик с его помощью будет получать прибыль).
Основное их содержание — бизнес-цели организации или клиента.
Результатом выявления требований на этом уровне является общее видение (vision and scope) — документ, который, как правило, представлен простым текстом и таблицами. Здесь нет детализации поведения системы и иных технических характеристик, но вполне могут быть определены приоритеты решаемых бизнес-задач, риски и т.п.
Несколько простых примеров бизнес-требований:
- Нужен инструмент, в реальном времени отображающий наиболее выгодный курс покупки и продажи валюты.
- Необходимо в два-три раза повысить количество заявок, обрабатываемых одним оператором за смену.
- Нужно автоматизировать процесс выписки товарно-транспортных накладных на основе договоров.
Пользовательские требования (user requirements) описывают задачи, которые пользователь может выполнять с помощью разрабатываемой системы (реакцию системы на действия пользователя, сценарии работы пользователя). Поскольку здесь уже появляется описание поведения системы, требования этого уровня могут быть использованы для оценки объёма работ, стоимости проекта, времени разработки и т.д. Пользовательские требования оформляются в виде вариантов использования (use cases), пользовательских историй (user stories), пользовательских сценариев (user scenarios).
Несколько простых примеров пользовательских требований:
- При первом входе пользователя в систему должно отображаться лицензионное соглашение.
- Администратор должен иметь возможность просматривать список всех пользователей, работающих в данный момент в системе.
- При первом сохранении новой статьи система должна выдавать запрос на сохранение в виде черновика или публикацию.
Бизнес-правила (business rules) описывают особенности принятых в предметной области (и/или непосредственно у заказчика) процессов, ограничений и иных правил. Эти правила могут относиться к бизнес-процессам, правилам работы сотрудников, нюансам работы ПО и т.д.
Несколько простых примеров бизнес-правил:
- Никакой документ, просмотренный посетителями сайта хотя бы один раз, не может быть отредактирован или удалён.
- Публикация статьи возможна только после утверждения главным редактором.
- Подключение к системе извне офиса запрещено в нерабочее время.
Атрибуты качества (quality attributes) расширяют собой нефункциональные требования и на уровне пользовательских требований могут быть представлены в виде описания ключевых для проекта показателей качества (свойств продукта, не связанных с функциональностью, но являющихся важными для достижения целей создания продукта — производительность, масштабируемость, восстанавливаемость). Атрибутов качества очень много, но для любого проекта реально важными является лишь некоторое их подмножество.
Несколько простых примеров атрибутов качества:
- Максимальное время готовности системы к выполнению новой команды после отмены предыдущей не может превышать одну секунду.
- Внесённые в текст статьи изменения не должны быть утеряны при нарушении соединения между клиентом и сервером.
- Приложение должно поддерживать добавление произвольного количества неиероглифических языков интерфейса.
Функциональные требования (functional requirements) описывают поведение системы, т.е. её действия (вычисления, преобразования, проверки, обработку и т.д.) В контексте проектирования функциональные требования в основном влияют на дизайн системы. Стоит помнить, что к поведению системы относится не только то, что система должна делать, но и то, что она не должна делать (например: «приложение не должно выгружать из оперативной памяти фоновые документы в течение 30 минут с момента выполнения с ними последней операции»).
Несколько простых примеров функциональных требований:
- В процессе инсталляции приложение должно проверять остаток свободного места на целевом носителе.
- Система должна автоматически выполнять резервное копирование данных ежедневно в указанный момент времени.
- Электронный адрес пользователя, вводимый при регистрации, должен быть проверен на соответствие требованиям RFC822
Нефункциональные требования (non-functional requirements) описывают свойства системы (удобство использования, безопасность, надёжность, расширяемость и т.д.), которыми она должна обладать при реализации своего поведения. Здесь приводится более техническое и детальное описание атрибутов качества. В контексте проектирования нефункциональные требования в основном влияют на архитектуру системы.
Несколько простых примеров нефункциональных требований:
- При одновременной непрерывной работе с системой 1000 пользователей, минимальное время между возникновением сбоев должно быть более или равно 100 часов.
- Ни при каких условиях общий объём используемой приложением памяти не может превышать 2 ГБ.
- Размер шрифта для любой надписи на экране должен поддерживать настройку в диапазоне от 5 до 15 пунктов.
Следующие требования в общем случае могут быть отнесены к нефункциональным, однако их часто выделяют в отдельные подгруппы (здесь для простоты рассмотрены лишь три таких подгруппы, но их может быть и гораздо больше; как правило, они проистекают из атрибутов качества, но высокая степень детализации позволяет отнести их к уровню требований к продукту).
Ограничения (limitations, constraints) представляют собой факторы, ограничивающие выбор способов и средств (в том числе инструментов) реализации продукта.
Несколько простых примеров ограничений:
- Все элементы интерфейса должны отображаться без прокрутки при разрешениях экрана от 800×600 до 1920×1080.
- Не допускается использование Flash при реализации клиентской части приложения.
- Приложение должно сохранять способность реализовывать функции с уровнем важности «критический» при отсутствии у клиента поддержки JavaScript
Требования к внешним интерфейсам (external interfaces requirements) описывают особенности взаимодействия разрабатываемой системы с другими системами и операционной средой.
Несколько простых примеров требований к внешним интерфейсам (внешнему взаимодействию):
- Обмен данными между клиентской и серверной частями приложения при осуществлении фоновых AJAX-запросов должен быть реализован в формате JSON.
- Протоколирование событий должно вестись в журнале событий операционной системы.
- Соединение с почтовым сервером должно выполняться согласно RFC3207 («SMTP over TLS»).
Требования к данным (data requirements) описывают структуры данных (и сами данные), являющиеся неотъемлемой частью разрабатываемой системы. Часто сюда относят описание базы данных и особенностей её использования.
Несколько простых примеров требований к данным:
- Все данные системы, за исключением пользовательских документов, должны храниться в БД под управлением СУБД MySQL, пользовательские документы должны храниться в БД под управлением СУБД MongoDB.
- Информация о кассовых транзакциях за текущий месяц должна храниться в операционной таблице, а по завершении месяца переноситься в архивную.
- Для ускорения операций поиска по тексту статей и обзоров должны быть предусмотрены полнотекстовые индексы на соответствующих полях таблиц.
Поскольку требований может быть очень много, а их приходится не только единожды написать и согласовать между собой, но и постоянно обновлять, работу проектной команды по управлению требованиями значительно облегчают соответствующие инструментальные средства — requirements management tools.
Требования к ПО
Требование к ПО (Software Requirements) = описание того, какие функции и с соблюдением каких условий должно выполнять приложение в процессе решения полезной для пользователя задачи.
Спецификации этих требований (Software Requirements Specification, SRS) детализируют требования к ПО до уровня, достаточного для разработки ПО для удовлетворения этих требований.
Пример SRS (2013)
Свойства качественных требований
- Завершённость (completeness). Требование является полным и законченным с точки зрения представления в нём всей необходимой информации, ничто не пропущено по соображениям «это и так всем понятно».
- Атомарность, единичность (atomicity). Требование является атомарным, если его нельзя разбить на отдельные требования без потери завершённости и оно описывает одну и только одну ситуацию.
- Непротиворечивость, последовательность (consistency) — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
- Недвусмысленность (unambiguousness, clearness) — требование должно быть описано без использования жаргона, неочевидных аббревиатур и расплывчатых формулировок, должно допускать только однозначное объективное понимание и быть атомарным в плане невозможности различной трактовки сочетания отдельных фраз.
- Выполнимость (feasibility) — требование должно быть технологически выполнимым и реализуемым в рамках бюджета и сроков разработки проекта.
- Обязательность, нужность (obligatoriness) и актуальность (up-to-date).
Если требование не является обязательным к реализации, оно должно быть просто исключено из набора требований. Если требование нужное, но «не очень важное», для указания этого факта используется указание приоритета. Также исключены (или переработаны) должны быть требования, утратившие актуальность - Прослеживаемость (traceability) — бывает вертикальной (vertical traceability) и горизонтальной (horizontal traceability).
Вертикальная позволяет соотносить между собой требования на различных уровнях требований, горизонтальная позволяет соотносить требование с тест-планом, тест-кейсами, архитектурными решениями и т.д.
Для обеспечения прослеживаемости часто используются специальные инструменты по управлению требованиями (requirements management tool) и/или матрицы прослеживаемости (traceability matrix). - Модифицируемость (modifiability) — характеризует простоту внесения изменений в отдельные требования и в набор требований.
Можно говорить о наличии модифицируемости в том случае, если при доработке требований искомую информацию легко найти, а её изменение не приводит к нарушению иных описанных в этом перечне свойств. - Проранжированность по важности, стабильности, срочности (ranked for importance, stability, priority). Важность характеризует зависимость успеха проекта от успеха реализации требования. Стабильность характеризует вероятность того, что в обозримом будущем в требование не будет внесено никаких изменений. Срочность определяет распределение во времени усилий проектной команды по реализации того или иного требования
- Корректность (correctness) и проверяемость (verifiability). Фактически эти свойства вытекают из соблюдения всех вышеперечисленных (или можно сказать, что они не выполняются, если нарушено хотя бы одно из вышеперечисленных).
Проверяемость подразумевает возможность создания объективного тест-кейса (тест-кейсов), однозначно показывающего, что требование реализовано верно и поведение приложения в точности соответствует требованию.
Источники требований
Требования начинают свою жизнь на стороне заказчика.
Их сбор (gathering) и выявление (elicitation) осуществляются с помощью следующих основных техник.
Техники сбора и выявления требований:
- Интервью. Самый универсальный путь выявления требований, заключающийся в общении проектного специалиста (как правило, специалиста по бизнесанализу) и представителя заказчика (или эксперта, пользователя и т.д.) Интервью может проходить в классическом понимании этого слова (беседа в виде «вопросответ»), в виде переписки и т.п. Главным здесь является то, что ключевыми фигурами выступают двое — интервьюируемый и интервьюер (хотя это и не исключает наличия «аудитории слушателей», например, в виде лиц, поставленных в копию переписки).
Начинать интервью с незнакомым стейкхолдером рекомендуется с т.н. контекстно-свободных вопросов.- Каковы ваши основные обязанности?
- Что и для кого вы в основном производите?
- Почему существует эта проблема?
- Как она решается сейчас?
- Как заказчик(пользователь) хотел бы её решать?
- Кто такие пользователи?
- Какое у них образование?
- Имеют ли пользователи опыт работы с данным типом приложений?
- Какой, по-вашему, должна быть производительность?
- Существуют ли другие вопросы, которые мне следовало бы вам задать?
- Работа с фокусными группами. Может выступать как вариант «расширенного интервью», где источником информации является не одно лицо, а группа лиц (как правило, представляющих собой целевую аудиторию, и/или обладающих важной для проекта информацией, и/или уполномоченных принимать важные для проекта решения).
- Анкетирование. Этот вариант выявления требований вызывает много споров, т.к. при неверной реализации может привести к нулевому результату при объёмных затратах. В то же время при правильной организации анкетирование позволяет автоматически собрать и обработать огромное количество ответов от огромного количества респондентов. Ключевым фактором успеха является правильное составление анкеты, правильный выбор аудитории и правильное преподнесение анкеты.
- Семинары и мозговой штурм. Семинары позволяют группе людей очень быстро обменяться информацией (и наглядно продемонстрировать те или иные идеи), а также хорошо сочетаются с интервью, анкетированием, прототипированием и моделированием — в том числе для обсуждения результатов и формирования выводов и решений. Мозговой штурм может проводиться и как часть семинара, и как отдельный вид деятельности. Он позволяет за минимальное время сгенери ровать большое количество идей, которые в дальнейшем можно не спеша рассмотреть с точки зрения их использования для развития проекта.
- Наблюдение. Может выражаться как в буквальном наблюдении за некими процессами, так и во включении проектного специалиста в эти процессы в качестве участника. С одной стороны, наблюдение позволяет увидеть то, о чём (по совершенно различным соображениям) могут умолчать интервьюируемые, анкетируемые и представители фокусных групп, но с другой — отнимает очень много времени и чаще всего позволяет увидеть лишь часть процессов.
- Прототипирование. Состоит в демонстрации и обсуждении промежуточных версий продукта (например, дизайн страниц сайта может быть сначала представлен в виде картинок, и лишь затем свёрстан). Это один из лучших путей поиска единого понимания и уточнения требований, однако он может привести к серьёзным дополнительным затратам при отсутствии специальных инструментов (позволяющих быстро создавать прототипы) и слишком раннем применении (когда требования ещё не стабильны, и высока вероятность создания прототипа, имеющего мало общего с тем, что хотел заказчик).
- Анализ документов. Хорошо работает тогда, когда эксперты в предметной области (временно) недоступны, а также в предметных областях, имеющих общепринятую устоявшуюся регламентирующую документацию. Также к этой технике относится и просто изучение документов, регламентирующих бизнес-процессы в предметной области заказчика или в конкретной организации, что позволяет приобрести необходимые для лучшего понимания сути проекта знания.
- Моделирование процессов и взаимодействий. Может применяться как к «бизнес-процессам и взаимодействиям» (например: «договор на закупку формируется отделом закупок, визируется бухгалтерией и юридическим отделом…»), так и к «техническим процессам и взаимодействиям» (например: «платёжное поручение генерируется модулем «Бухгалтерия», шифруется модулем «Безопасность» и передаётся на сохранение в модуль «Хранилище»). Данная техника требует высокой квалификации специалиста по бизнес-анализу, т.к. сопряжена с обработкой большого объёма сложной (и часто плохо структурированной) информации.
- Самостоятельное описание. Является не столько техникой выявления требований, сколько техникой их фиксации и формализации. Очень сложно (и даже нельзя!) пытаться самому «придумать требования за заказчика», но в спокойной обстановке можно самостоятельно обработать собранную информацию и аккуратно оформить её для дальнейшего обсуждения и уточнения.
Трассировка требований
Requirements traceability = трассируемость требований = прослеживаемость требований = отслеживаемость связей требований.
Трассировка помогает понимать связи требовний, понимать откуда вообще в системе та или иная функциональность или системное ограничение, какой бизнес-цели они служат.
Например, установление сквозной связи между:
- Потребности клиента — Требования — Основные элементы Системы
- Потребности клиента — Бизнес-требования — user stories и use case Системы — Тесты
Для чего нужно:
- удостовериться, что мы реализуем именно то что требуется
- удостовериться, что мы не забыли что-то учесть, т.е. система покрывает все требования, которые покрывают все целы/нужды/потребности заказчика/клиента
- удостовериться, что мы покроем тестами все необходимые функции
- увидеть на что (требования, архитектура, компоненты) может повлиять добавление/изменение/удаление тех или иных требований
- и т.д.
скачать схему в формате diagrams.net (бывший draw.io)
| определяет, основание для —> | |||
|---|---|---|---|
|
|
|
|
Тест-кейсы можно увязать к Компонентам ПО, как объектам самого низкого уровня Системы — архитектурного слоя Software. Ниже только физический.
Управление требованиями
Управление требованиями = принятие управленческий решений о:
- Приоритетах требований
- Рамках продукта (какие требования включать, какие — нет), оно же — scope management из того же PMBOK, включая сортировку входящих внешних требований — какие требования из других проектов включать, а какие — нет.
- Рамках итерации
- Чего проект требует от других проектов — исходящие требования
Эти решения принимает Менеджер, и даже если выдвигает часть из них Аналитик — всё равно несёт ответственность за них Менеджер.
То, что физически в учётной системе атрибуты Приоритет, Релиз, Итерация, Источник, Потребитель проставляет, например, Аналитик, ещё не делает его «управленцем требований», он тут просто учётчик, оператор БД.
Также, технически, под гриф «управления требованиями» попадают:
- Управление статусом требований
- Управление внутренними трассировками требований
- Управление трассировками требований на другие артефакты проекта
С этими атрибутами, действительно, Менеджеру возиться не интересно и он может доверять всю эту работу Аналитику.
Но если посмотреть на жизненный цикл требований и на трассировки, то станет понятно, что Аналитик отвечает только за часть переходов и за внутренние трассировки, а за переходы типа «разработано —> протестировано» и за трассировки требований на тесты, например, отвечает уже Тестировщик.
Есть мнение, что управление требованиями — это не задача аналитика.
Прежде всего потому, что управление — это управление, а разработка — это разработка:
TBD
Use case (вариант использования)
Определения
Use case = последовательность действий в диалоге между Актором и Компонентом/Системой с получением значимого результата, где Актором может быть пользователь или что-то, что может обмениваться информацией с Системой.
Юзкейс = текст,
описывающий сценарий
взаимодействия Актора с Системой,
приводящий
к значимому (для кого-то) результату.
Простейшие примеры диаграмм вариантов использований
Простейший пример варианта использования
UC1. Регистрация пассажира на рейс.
| Базовая часть Use Case | |
|---|---|
| Система регистрации пассажира на рейс | |
| Пассажир | |
| Зарегистрироваться на рейс | |
| Пассажир решает зарегистрироваться на рейс и заходит на страницу регистрации сайта | |
| Информация о регистрации пассажира сохранена. У пассажира есть посадочный талон. | |
| Основной поток событий | |||
|---|---|---|---|
| 1 | Система | Запрашивает фамилию и код бронирования | |
| 2 | Пассажир | Вводит фамилию и код бронирования | Код бронирования: 7 символов, заглавные латинские и цифры. Например: MTDTC1 |
| 3 | Система | Проверяет, что приобретен билет на этот рейс на имя этого Пассажира | |
| 4 | Система | Сохраняет информацию о регистрации Пассажира на рейс | |
| 5 | Система | Подтверждает Пассажиру, что он зарегистрирован на рейс | |
| 6 | Система | Выводит для печати посадочный талон | |
| 7 | Пассажир | Отправляет посадочный талон на печать | |
На самом деле большую часть реального полного Use Case составляет не основной поток, а альтернативные потоки, которые позволяют задавать ветвления потока, циклы и обрабатывать «неправильные» события. Подробнее — читать в книге Ivar Jacobson. Use-case 2.0.
Use Case для руководителя проекта
Сам по себе Use Case — это естественный способ описывать диалог, он понятен человеку без подготовки, Use Case обычно не содержит деталей реализации и пишется на языке целей пользователей.
Поэтому Use Case удобно согласовывать с Заказчиком как «единицу поставки»: элемент планирования работы над системой и сдачи проекта.
Use Case для тестировщика
Для тестировщиков Use Case являются отличной базой для формирования тестовых сценариев (test case), так как они описывают в каком контексте должно производиться каждое действие пользователя.
Use Case, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.
Use Case для Аналитика и Продукт-Менеджера
Для аналитика и менеджера продукта, как наиболее частых авторов, Use Case это отличный инструмент:
- разработки и подспорье в обеспечении полноты функциональных требований
- выявления других видов информации (нефункциональных требований), которая необходима для работы над проектом:
- ограничений
- атрибутов качества
- требований к пользовательскому интерфейсу
- внутренних правил работы в предметной области (бизнес-правил)
- обеспечения трассировки требований между исходными требованиями заказчика (бизнес-требованиями) и техническими требованиями (не только функциональными).
Ограничения метода
Use Case не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.
User story (пользовательская история)
Пользовательские истории (user story) = способ описания Требований к разрабатываемой Cистеме, сформулированных как одно или более предложений на повседневном или деловом языке пользователя.
Пользовательские истории используются гибкими методологиями разработки ПО для спецификации требований (вместе с приёмочными испытаниями). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой.
Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.
Пользовательские истории обычно записываются в следующем формате:
As a <type of user>, I want <some goal> so that <some reason>.
Как <роль пользователя>, я <что-то хочу получить> <с такой-то целью>.
Примеры:
Как гость я могу зарегистрироваться в системе для получения пользовательской учетной записи и последующей работы.
Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.
Как пользователь я могу сделать некоторые поля своей учетной записи видимыми для других пользователей.
Как пользователь я могу хранить свои фотографии в системе, чтобы иметь возможность показать их другим пользователям
Сфер в IT много, но путь становления Senior-разработчика плюс-минус одинаков. В этой статье мы поговорим о том, кто такой старший разработчик, какие к нему предъявляются требования и как дорасти до столь солидной должности.
- Кто такой Senior программист?
- Что должен знать и уметь сеньор разработчик?
- Дополнительные материалы
Кто такой Senior программист?
Если не вдаваться в дебри специализаций, это одна из ступеней развития разработчика в цепочке Junior → Middle → Senior. Перед джуном также может указываться стажёр, а после сеньора — тимлид, но мы рассмотрим именно трёхэтапную схему.
Junior разработчик
Сразу оговоримся, что чётких научных измерений в этой системе нет. Для каких-то компаний джун — это вчерашний студент с минимальными знаниями и нулевым опытом, а кто-то ищет младших разработчиков с опытом работы от 2-х лет.
Но практически все сходятся в том, что это наименее ответственное звено, в развитие которого нужно вкладываться, отслеживать и координировать его действия. Скажем, это человек, который, работая, продолжает учиться.
Middle разработчик
По сути, это «подросший» Junior, который освоил необходимый стек технологий, уверенно обращается с Git, командной строкой, самостоятельно и в срок решает поставленные задачи.
Кроме того, Middle — это командный игрок, который может и чужой код прочесть, и дельное замечание по нему сделать, если требуется.
Где-то между джуном и мидлом есть ещё так называемые «уверенные джуны», но это, скорее, не промежуточный этап, а просто попытка компаний оставить уже обросшего опытом специалиста на позиции и зарплате Junior-разработчика. Как только почувствовали, что знаете и можете гораздо больше, чем джун, сразу же обсудите это с руководством.
Senior разработчик
Вот он, гвоздь программы, способный взять на себя проект и даже руководить отдельным подразделением. Senior Developer обладает обширным багажом знаний, способен стать ментором для Trainee или Junior разработчика, а также улучшать эффективность команды за счёт реализации своих идей.
Грубо говоря, если вы не нуждаетесь в сторонней помощи и, напротив, сами можете предоставить такую помощь, в числе первых берёте на абордаж новые технологии и не боитесь использовать их на практике, вы Senior программист.
Что должен знать и уметь сеньор разработчик?
Так как же стать Senior разработчиком? Не стойте на месте: осваивайте новые языки и технологии, записывайтесь на вебинары, бросайтесь в принципиально новые подходы, дабы не пасти задних, и развивайтесь всесторонне.
Довольно обобщённые советы, не правда ли? Что ж, попытаемся их структурировать и раскрыть подробнее.
1. Технические навыки
Во-первых, это понимание алгоритмов и умение писать чистый код. Во-вторых, для одной задачи существует множество решений, но именно Senior Developer способен определить, какое из них оптимально в конкретном случае.
Перед началом работы всегда спрашивайте себя:
- Можно ли разбить таск на подзадачи, и если да, то как?
- Какой подход к решению этой задачи наиболее оптимален?
- Смогу ли я подключить других сотрудников, и как в таком случае организовать рабочий процесс?
Если для решения проблемы нужно освоить новую СУБД, фреймворк или сторонний сервис, вы осваиваете это.
Но что реально отличает сеньора от остальных, так это опыт поддержки проектов, даже если речь идёт о всеми забытом и припорошенном пылью легаси коде.
Кроме того, чтобы думать, как Senior, нужно расширять способы обработки информации. В этом поможет книга Иана Макдермотта и Джозефа О`Коннора «Искусство системного мышления». Также есть краткая выжимка основных мыслей в формате аудиокниги:
2. Коммуникативные навыки
Не будем распыляться о том, что старший разработчик должен хорошо знать английский язык. В любом случае держите бесплатные материалы по английскому для айтишников.
Как вы уже поняли, сеньоры часто ведут проекты самостоятельно, поэтому очень важно уметь обрабатывать ТЗ заказчика, задавать правильные вопросы, которые выльются в исчерпывающие ответы, устанавливать сроки выполнения и выстраивать план работ. Разумеется, проджект-менеджеров никто не отменял, но в идеале старший разработчик может справляться и без их помощи.
А ещё программирование — это почти всегда работа в команде, поэтому нужно уметь организовать процесс, отталкиваясь от навыков и запросов других сотрудников. Вы должны быть на «ты» с гибкими методологиями разработки, и такие термины, как Agile, Scrum и Kanban, не должны вас пугать.
3. Навыки ментора и интервьюера
Подбор персонала и обучение новичков — задачи, которые нередко ложатся на плечи сеньоров. Как человек, прошедший обучение, становление и набивший достаточное количество шишек, Senior-программист прекрасно знает, какие вопросы задавать, чтобы выделить сильные и слабые стороны кандидата, а также как организовать рабочий процесс для тех, кто уже прошёл собеседование.
Нелишним будет прочесть книги «HBR Guide. Эмоциональный интеллект» и «Как разговаривать с кем угодно, когда угодно и где угодно».
4. Навыки профессионального роста
Если вы думаете, что дослужитесь до звания Senior Developer и закончите на этом свой учебный путь, вы ошибаетесь. Старшие разработчики как никто знают, сколь важно постоянно развиваться, осваивая всё новые и новые горизонты. Они никогда не ограничиваются одним набором инструментов, ведь в погоне за оптимизацией рабочего процесса так или иначе приходится обращаться к чему-то новому.
Если у вас есть боязнь применения новых знаний на практике, также известная как синдром вечного студента, вам нужно её преодолеть, чтобы стать Senior разработчиком.
Принципиальная разница между джуном и сеньором в том, что первый, как правило, воспринимает обучение как обязаловку, в то время как второй видит в этом ценную необходимость, ключ от закрытых дверей.
От сеньора редко можно услышать что-то вроде «Ненавижу этот инструмент», поскольку он уже изучил его, выделил все плюсы и минусы, знает, когда его стоит применять, а когда это бесполезная трата времени и ресурсов.
5. Навыки работы с сообществом
Мало того что старшие программисты хорошо выполняют свою работу, так они ещё и «подтягивают» айтишное комьюнити. Часто выступают с докладами, организовывают митапы, пишут документации и полезные статьи, которые помогают развиваться другим.
Иными словами, Senior разработчик не закрывается в своём рабочем пространстве, втихую накапливая знания и скрывая их от остальных. Скорее, это те самые гуру, раздающие дельные советы на Stack Overflow. Они любят делиться своим опытом, так как это:
- помогает взращивать новые поколения талантливых разработчиков и способствует развитию IT в целом;
- в ходе общения позволяет почерпнуть полезную информацию и от самого сообщества.
Вместо эпилога
Всё сказанное уже сказано, поэтому просто держите несколько дополнительных материалов, чтобы лучше понять, как стать Senior разработчиком:
- Отличия junior, middle и senior разработчиков — объясняют эксперты
- Практическое руководство как стать Senior Frontend Developer
Тематический трафик – альтернативный подход в продвижении бизнеса
Получи нашу книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».
Подпишись на рассылку и получи книгу в подарок!
SEO-текст — это текстовый материал, который оформлен по правилам поискового маркетинга: вписаны ключи, соблюдена структура и соблюдены критерии качества контента.
Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA
Представьте, что на заборе висит объявление:
- “Квартира продать хачу 3х-комн. кухня есть в квартире еще с мебелью и окна квартиры выходят во двор”.
И рядом другое: - “Продается 3х-комнатная квартира, 120/65/12, ремонт. Обмен на 2 +1 с нашей доплатой”.
Это два похожих объявления о продаже недвижимости. Какое из них для вас понятнее? Если вы ищете квартиру — то по какому из двух объявлений вы позвоните? Конечно, по второму — точному, оптимизированному, дающему полную информацию о продаваемом объекте недвижимости. Ключевые слова “Зх-комнатная квартира” вписаны аккуратно, в тексте нет ошибок. Это и есть пример SEO-текста.
Самое главное для поисковика — это контент. Поэтому очень важно уделять внимание текстовому содержимому сайта, в котором встречаются ключевые запросы (КЗ). Именно по ним потенциальные клиенты находят сайты, вбивая запрос в поисковую систему.
После того, как посетитель вводит запрос, поисковик выдает ему наиболее релевантные (удовлетворяющие его запрос) страницы сайтов. Главная задача любого сеошника — “продвинуть” сайт в ТОП10 (на первую страницу) этой поисковой выдачи. Поэтому от того, насколько грамотно будут проработаны SEO-тексты сайта, зависят его позиции по ключевым запросам.
Хорошие и плохие SEO-тексты
Не так давно поисковики с удовольствием принимали и выдавали на первые позиции страницы, “заспамленные” ключевыми словами. В настоящее время ситуация изменилась, и поисковые системы обращают внимание на качество контента.
Плохой сео-текст поисковая система не пропускает в ТОП выдачи. Сайт может быть наказан за переспам и откровенное манипулирование поисковыми системами. Страница может попасть в “сопливый” индекс Гугла или вообще не проиндексироваться Яндексом.
Пример плохого SEO-текста:
В тексте невооруженным глазом видны ключевые слова, которые, к тому же, употреблены один за другим, без каких-либо изменений. Ключи нельзя вписывать так явно и так часто.
Как составить ТЗ для копирайтера:
- Дайте название тексту для каждой страницы или определите его тему.
- Задайте необходимый объем символов для каждой страницы (без учета пробелов).
- Определите список ключей для каждой страницы.
- Составьте план текста.
- Установите необходимые значения параметров: спам, стоп-слова, объем, уникальность.
Должен знать каждый копирайтер: важные составляющие SEO-текстов.
Не используйте часто сложноподчиненные предложения
Сложные предложения должны разбавляться простыми. SEO-тексты пишутся не только для поисковиков, но и для посетителей сайта, поэтому они не должны испытывать сложности при восприятии материала.
Тема должна быть раскрыта максимально полно
Если человек ищет, “что такое продвижение сайта” — именно из вашей статьи он должен почерпнуть знания о том, что это такое, как работают поисковики, какие принципы ранжирования документов применяются, почему некоторые сайты есть в ТОП, а других не видно, и что нужно делать, чтобы добиться первых позиций.
Критерии качества соблюдены
- Минимальный желательный объем статьи — 3000 знаков.
- Минимальная уникальность текста — от 95%.
- Наличие “воды” в документе не должно превышать 50%.
- Количество стоп-слов — до 10%, спама — до 50%.
- Академическая тошнота — до 15%.
Текст не должен быть переспамлен. Это касается и ключей и любых других слов. Проверьте часто употребляемые в тексте слова на частоту вхождений. Если в рамках одного абзаца вы встретите одно и то же слово 2, 3 и более раз — вам нужно пересмотреть написание текста и убрать лишнее или заменить синонимами.
Вода — соотношение стоп-слов к общему их числу в документе.
Стоп-слова — “шум” в документе, слова, не несущие смысловой нагрузки.
Академическая тошнота — отношение числа всех слов к КЗ.
Указанные характеристики документа вы можете проанализировать при помощи сервисов Text.ru и Advego. Данные показатели являются “плавающими” и сильно зависят от тематики сайта. Поэтому просто старайтесь не переусердствовать с ключами и следите за качеством материала.
Как вписывать ключевые запросы
- Каждая статья должна иметь привлекательное название (заголовок), в котором используется КЗ. Самый частотный ключевик должен обязательно упоминаться в заголовке. Возможно употребление словоформ, склонений, разбиение ключей сторонними словами, скрещивание их.
- Ключевые запросы должны встречаться в подзаголовках.
- Какой-либо поисковый запрос (желательно, высокочастотник) обязательно должен встретиться в первом и последнем абзацах.
- Ключи вписываются в тело статьи гармонично. Читатель не должен спотыкаться при изучении материала. К примеру, фраза “Если вы хотите купить мягкуюу мебель Воронеж дешево — обращайтесь к нам!” имеет негармонично вписанный ключ.
- Не употребляйте много родственных КЗ в одном абзаце.
- Распределяйте их по телу текста равномерно. Один КЗ в двух повторениях должен разбиваться хотя бы 1-2 предложениями без ключей (от 500 символов).
- Раскройте информацию для каждого из ключевых запросов. Если в теме про кактусы вам попался ключевик с четким уточнением, например, “полив кактуса зимой”, не нужно просто вписывать куда-нибудь, лишь бы зафиксировать его в тексте. Напишите про тонкости полива в зимний период, иначе от ключа не будет никакого толку.
Правила качественного текста
Помимо правильной оптимизации, о которой мы рассказывали выше, каждый текст должен соответствовать определенным правилам.
- Высокая уникальность.
- Отсутствие ошибок.
- Хорошая структура (абзацы, отступы, списки, заголовки и подзаголовки).
- Цитаты выделяются курсивом, важные понятия — жирным шрифтом. Ссылки по тексту — подчеркнуты и видны.
- Размер заголовков крупнее, чем размер основного шрифта.
- Причем, заголовок H1 — самый крупный шрифт, H2 — меньше, и т.д.
- Указаны ссылки на первоисточники (если часть текста берется со сторонних сайтов).
- Грамотная перелинковка.
- И всегда следуйте главному правилу — любой текст должен быть для людей!
Пример некачественной статьи:
В приведенном примере очень много ошибок: неправильно употреблены составляющие словосочетаний “быстрые сроки”, “кто хочет быть уверен”, “без ненужных затрат”, “сделан без шаблонного дизайна”; также нет знаков препинания в списках, расставлены неуместные скобки и т.д.
Не спешите сразу же размещать готовую статью. Проверьте ее несколько раз, а только потом размещайте. Если поисковик быстро проиндексирует некачественный контент, то, возможно, что возникнут трудности с “приглашением”, чтобы он посетил данную страницу еще раз. Помните: правильный контент на сайте — залог успеха.