Описывает то что должна сделать программа но не как она должна это сделать

Представим, что вы планируете разработать большой проект: сайт, блог или приложение. Чего вы боитесь как заказчик? Что подрядчик пообещает золотые горы, возьмёт деньги, но не сделает, что вы хотели. А как подрядчик? Что в начале работы вас попросят сделать одно, а в процессе — всё переделать (причём раз десять), в итоге вы потратите кучу времени и уйдёте в минус.

Проект большой, поэтому надо принять меры. И поможет в этом спецификация (в простонародье — спека). В этой статье я расскажу, как готовить спецификацию к масштабному проекту, на примере нашей недавней работы с крупным клиентом.

Что такое спецификация?

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

Спека похожа на список продуктов перед походом в магазин. Запишите и структурируйте всё, чтобы не забыть «купить». Это по сути договор между вами и заказчиком, который регулирует объём будущих выполненных работ.

Михаил Хазин — Этот год будет очень интересным.

Подготовку спецификации можно разделить на пять шагов.

1. Закрытая или открытая?

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

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

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

2. Содержание

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

Ну и какая дипломная работа спецификация без титульного листа! Добавьте на него заголовок и дату публикации.

3. Разделы

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

1. Введение

1. Обзор : цель спецификации.
2. Объём проекта : краткое описание проекта.
3. Глоссарий : расшифровка терминов.
4. Ссылки : список источников.
5. Обзор продукта : краткое описание каждого раздела

1. Системная среда : общее описание, при помощи каких инструментов будет реализован функционал продукта.
2. Спецификация функциональных требований : подробное описание, из чего состоит продукт. Если вы создаёте сайт, здесь будет подробное описание всех его страниц, хедера, футера и так далее.

1. Требования к интерфейсу : общее описание требований к возможностям интерфейса проекта. Если продолжать пример с сайтом, то в этом разделе можно указать домен, на котором он будет размещаться, место хранения базы данных и используемые API.
2. Функциональные требования : описание того, как должна работать система со стороны пользователя. Здесь, например, можно описать карту сайта, работу пагинации, RSS и счётчики аналитики.
3. Нефункциональные требования : описание того, что нужно сделать, чтобы реализовать функциональные требования. Так сказать, начинка продукта. К примеру, описание страниц ошибок, навигации по сайту, требования к производительности и безопасности данных.

О последних двух подпунктах расскажу подробнее.

Основы Программирования — #1 — Логика. Алгоритмы

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

Это основная и самая подробная часть спецификации. Ей нужно уделить особое внимание, но сначала давайте разберёмся, в чём разница между этими требованиями.

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

Ещё один пример: описание работы комментариев на сайте

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

Другой пример нефункционального требования — безопасности

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

5. Согласование

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

Далее отдайте спеку заказчику на первую оценку. Возможно, согласование займёт несколько итераций, но это неотъемлемая часть работы.

Как только спека согласована, остаётся подписать её вместе с заказчиком и приступать к работе.

В сухом остатке

Информации было много, давайте закрепим:

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

Источник: emailmatrix.ru

Декларативное и императивное программирование: 5 ключевых отличий

Изучение

На чтение 9 мин Просмотров 622 Опубликовано 27.07.2022

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

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

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

Что такое императивное программирование?

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

Пошаговый процесс содержит отдельные операторы, инструкции или вызовы функций. В мире программирования этот процесс называется потоком управления.

Другими словами, вас интересует, как работает программа, и вы даете ей четкие инструкции. Проиллюстрируем это на примере псевдокода.

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

Begin Accept location from user input of either location name or ZIP code. Call OpenWeather’s Geocoding API to convert location data into geographic coordinates. Call OpenWeather’s Current Weather Data API. Send geographic coordinates to OpenWeather. Call OpenWeather’s Daily Forecast 16 Days API.

Resend geographic coordinates. Parse JSON returned by the APIs to extract current weather and forecast data. Return current weather and forecast. Display current weather and forecast to user. End

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

Примеры императивных языков программирования включают:

Поддержка обеих парадигм

На самом деле вы можете использовать Python как в декларативном, так и в императивном программировании. За прошедшие годы некоторые другие императивные языки также получили обновления, позволившие им поддерживать программирование в декларативном стиле. К ним относятся JavaScript, C++ и C#.

В частности, за последние годы в C++ было внесено несколько улучшений, многие из которых сделали C++ более декларативным. Например, более новые версии C++ имеют стандартную библиотеку шаблонов (STL), которая предоставляет четыре компонента: алгоритмы, контейнеры, функции и итераторы.

Среди этих компонентов есть несколько встроенных функций или операций, которые ранее выполнялись вручную, например std::sortи std::list. Теперь вы можете легко использовать std::sortи продолжать кодирование без необходимости разработки императивного алгоритма сортировки.

Следующий пример кода демонстрирует эту функцию в действии:

Источник: bestprogrammer.ru

Основы UML — диаграммы использования (use-case)

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

Диаграмму вариантов использования есть смысл строить во время изучения технического задания, она состоит из графической диаграммы, описывающей действующие лица и прецеденты, а также спецификации, представляющего собой текстовое описание конкретных последовательностей действий (потока событий), которые выполняет пользователь при работе с системой. Спецификация затем станет основой для тестирования и документации, а на следующих этапах проектирования она дополняется и оформляется в виде диаграммы (в рамках ICONIX используется диаграмма последовательности, но в UML для этого имеются также диаграммы деятельности). Кроме того, use-case диаграмма достаточно проста, чтобы ее мог понять заказчик, следовательно вы можете использовать ее для согласования ТЗ (ведь диаграмма описывает функциональные требования к системе).

На диаграмме использования изображаются:

• акторы — группы лиц или систем, взаимодействующих с нашей системой;
• варианты использования (прецеденты) — сервисы, которые наша система предоставляет акторам;
• комментарии;
• отношения между элементами диаграммы.

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

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

Сценарии являются очень важной частью диаграмм использования, хотя их формат и не регламентирован. Ряд авторов предлагает использовать псевдокод для представления сценария и даже сразу строить диаграммы деятельности или взаимодействия, но на мой взгляд, наиболее предпочтительным вариантом на этапе построения use-case диаграмм является текстовый, описывающий систему с точки зрения пользователя (т.к. именно этот формат будет наиболее понятен заказчику, с которым вам предстоит согласовывать техническое задание).

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

• для учеников:

• выбор подготовленного учителем блока заданий;
• выполнение заданий;

• подготовка для учеников блоков заданий;
• добавление в систему ученика;
• просмотр отчетов.

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

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

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. система добавляет ученика;
5. учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель нажимает кнопку «назад»;
4. учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

Аналогичным образом должны быть прописаны все прецеденты, изображенные на диаграмме. Составлять сценарии нужно достаточно упорно чтобы описать все возможные варианты действий пользователя в системе. Заказчик может делать это с большим удовольствием, а программист за счет этого раньше узнает возможные пожелания заказчика (так из приведенного сценария он мог бы выяснить, что программа должна отображать всплывающие уведомления).

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

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

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

Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.

На последней диаграмме используется символ комментария для задания условий расширения, при этом комментарий связывается пунктирной линией с отношением расширения, т.к. относится к нему. В ряде публикаций по UML и ICONIX предлагается описывать с помощью комментариев на диаграмме прецедентов:

• нефункциональные требования к системе (при этом используется стереотип >);
• сценарии вариантов использования (связывая комментарий с соответствующим прецедентом);
• детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали).

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

• неправильное использование отношений расширения и включения, в том числе попытки использовать диаграммы для функциональной декомпозиции системы. Возникает из-за непонимания различий между этими двумя видами отношений и того, что use-case диаграмма должна выражать лишь требования к системе, а не детали ее реализации;
• разработка диаграммы с точки зрения программиста, а не пользователя. В сценариях должны использоваться названия элементов управления (видимые пользователю), но нежелательно изображать детали реализации (такие как менеджер событий), не понятные заказчику;
• не достаточная проработка сценариев:

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

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

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

Источник: pro-prof.com

Как написать хорошую инструкцию: 5 шагов, полезные советы, пример

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

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

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

Для чего нужна любая инструкция

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

1. С точки зрения читателя — это решение его проблемы, в том или ином вопросе, в зависимости от тематики сайта, на котором она опубликована;
2. С точки зрения заказчика (владельца сайта) — привлечения целевого трафика, а как следствие потенциальных клиентов;
3. С точки зрения копирайтера — написание качественного текста, который принесет доход или упорядочит информацию в голове.

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

Какие бывают инструкции

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

Но некоторой классификации, в общих чертах, инструкции всеже можно подвергнуть, и так какие виды инструкций бывают:

1. Инструкция по строительству или сборке чего-либо;
2. Инструкция по применению чего-либо;
3. Медицинская инструкция;
4. Инструкция из разряда «Как сделать…»;
5. Инструкция по приготовлению пиши (рецепт);

Естественно, это далеко не весь перечень, даже самых распространенных видов инструкций, но наиболее известный — это точно.

Существует отдельный вид инструкций, я его называю «специфический», к нему можно отнести:

1. Пошаговую инструкцию как написать книгу;
2. Инструкцию как в домашних условиях сделать что-то для этого не предназначенное;
3. Инструкция как вести себя в той или иной ситуации.

И аналогичные этому.

Как написать пошаговую инструкцию (самое интересное)

По сути, эта статья — инструкция как написать инструкцию, плюс неплохо заточенные под СЕО текст с ключами. То есть, структура, выделенные ключи и заголовке в этой статье — это уже первый пример инструкции.

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

1. Найдите проблему — это очень важный этап. Кроме того, проблема, которую решит ваша инструкция должна полностью соответствовать тематике вашего сайта или сайта заказчика;
2. Разобраться в вопросе — полностью, досконально и глубоко разобраться в вопросе, о котором будете писать инструкцию;
3. Разбить решение проблемы на шаги — составе план, в котором первым пунктом будет наличие проблемы, а последним описание результата ее решения. Промежуточными же пунктами должны стать, последовательные, четкие, полные и грамотные шаги по достижению цели;
4. Распишите более подробно каждый шаг — даже уже написав текст в него всегда есть что добавить. Пусть последовательность решения проблему будет максимально подробной;
5. Схемы, картинки, примеры — добавьте в статью максимально доступную визуальную информацию. Ее должно быть немного, но в тоже время и не мало. Но помните, что не для всех инструкций такой ход необходим, как, скажем, в этой;
6. Полезные советы — добавите вставки в текст с полезными советами (также не для всех видов инструкций);

И вот теперь, как написать инструкцию, образец плана выше, можно понять наглядно, но еще прочитав эту статью и хорошо ее проанализировав, можно понять, как написать СЕО-текст с определенной тематикой.

Вы пришли сюда из поиска? Это доказывает вышесказанное.

Как написать инструкцию: пример

Как я уже говорил выше, пример написания инструкции — это вся эта статья. Более того, большинство статей на этом сайте, которые начинаются со слова «Как» — являются инструкциями, в той или иной степени.

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

Источник: yourwriter.ru