Способы писать характеристику – базовые требования к содержанию

Пример написания функциональных требований к Enterprise-системе

Способы писать характеристику - базовые требования к содержанию

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

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

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

Целью нашей разработки было создание с нуля учетной системы для одной из крупных российских компаний. Система была призвана заменить текущую, написанную в конце 90-х. В результате были реализованы платформа и один из бизнес-модулей. В реализованной части было порядка 120 объектов, 180 таблиц, около 30 печатных форм.

Хочу оговориться, что подход, описанный ниже, не универсален для написания любого ПО. Он подходит для систем уровня предприятия, которые строятся на основе объектно-ориентированного подхода: учетных, CRM-, ERP-систем, систем документооборота и т.п.

Вся документация на наш программный продукт состояла из следующих разделов:

  • Общая часть • Список терминов и определений • Описание бизнес-ролей
  • Требования • Бизнес-требования
    • Общие сценарии
    • Сценарии использования
    • Алгоритмы и проверки

    • Системные требования • Нефункциональные требования • Требования к интеграции

    • Требования к пользовательскому интерфейсу

  • Реализация
  • Тестирование
  • Руководства
  • Управление

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

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

Бизнес-требования состояли из общих сценариев, сценариев использования (use cases) и описания алгоритмов обработки данных. Подробно о разработке подобного рода требований можно узнать из книги Карла И.

Вигерса и Джоя Битти Разработка требований к программному обеспечению.

Системные требования описывали свойства и методы всех объектов системы.

Нефункциональных требований в данной статье мы касаться не будем. Могу лишь отослать вас к отличной книге Architecting Enterprise Solutions авторов Paul Dyson, Andrew Longshaw.

Требования к интеграции описывали низкоуровневый интерфейс взаимодействия новой системы с несколькими другими системами компании. Здесь мы их рассматривать не будем.

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

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

Список терминов и определений

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

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

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

Поясню это на примере термина Пользователь. Википедия дает такое определение:

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

Но нас оно не устраивало по нескольким причинам. Во-первых, в систему может зайти только человек, но не организация. Во-вторых, для нашей системы некорректно настоящее время глагола «использует» — система хранит данные о неактивных или удаленных пользователях, т.е. о тех, которые использовали систему ранее, но не могут в настоящее время. И наконец, у нас есть данные о потенциальных пользователях. Например, мы регистрируем сотрудника компании-клиента, который в дальнейшем может получить (а может и не получить) доступ в систему. Наше определение:

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

Теперь программист, прочитав определение, сразу поймет, почему свойство Логин в объекте Пользователь не обязательное. Термины связаны друг с другом. В термине Пользователь используется «операция», поэтому приведу и ее определение:

Операция — совокупность действий, составляющих содержание одного акта бизнес-деятельности. Операция должна соответствовать требованиям ACID (Atomicity, Consistency, Isolation, Durability). Совокупность операций одного модуля представляет интерфейс взаимодействия клиент-сервер этого модуля.

Как видите, это определение очень важно для всей системы – оно не только связывает пользователя и его бизнес-действия с тем, что должно быть реализовано, но и накладывает требования на то, КАК должна быть реализована система (это КАК было определено ранее при разработке архитектуры) – бизнес-действия внутри операции должны быть внутри транзакции. Работа над списком терминов происходила постоянно. Мы поддерживали его полноту, т.е. старались, чтобы в документации не было термина, который бы не был определен в этом списке. Кроме того, были случаи, когда мы меняли термины. Например, по прошествии нескольких месяцев с начала написания требований мы решили заменить Контрагент на Компания. Причина была проста: оказалось, что никто не в состоянии в речи, при разговоре, использовать слово «контрагент». А если так, то он должен был быть заменен на что-то более благозвучное. Часто бывали случаи, когда приходилось прерывать обсуждение и лезть в требования, чтобы понять, подходит ли обсуждаемая функциональность под существующие определения. И для того, чтобы поддержать непротиворечивость требований, мы в итоге должны были или изменять реализацию, или корректировать описания терминов. В итоге в списке у нас оказалось порядка 200 бизнес- и системных определений, которые мы использовали не только во всей документации, включая, например, и технический дизайн, разрабатываемый программистами, но и в разговоре, при устном обсуждении функциональности системы. Второй частью, на которую опиралась вся документация, было описание бизнес-ролей.

Описание бизнес-ролей

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

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

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

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

Уровни требований

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

Мы использовали 4 – три уровня бизнес-требований плюс системные требования: Бизнес-требования

  1. Общие сценарии (соответствует уровню очень белого у Коберна)
  2. Сценарии использования (соответствует голубому)
  3. Алгоритмы и проверки (скорее черный)

4.

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

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

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

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

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

Вы однозначно можете уважать программиста, который читает сценарии использования. Тестировщикам (как и аналитикам) нужны все уровни требований, поскольку им приходится проверять систему на всех уровнях. Использование wiki позволяло работать над требованиями параллельно всем членам проектной команды. Замечу, что в один и тот же момент разные части требований находились в разных состояниях: от находящихся в работе до уже реализованных.

Общие сценарии

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

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

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

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

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

Некоторые другие цели общих сценариев:

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

Вот пример одного из общих сценариев: Как видите, только половина шагов автоматизирована, да и те описаны как можно более кратко. Также из первого шага видно, что ручной перевод задания на печать в статус ‘В работе’ в принципе лишний, можно упростить работу пользователя и автоматически переводить задание в этот статус при печати. Ссылка «Задание на печать», указывающая на описание объекта в системных требованиях, лишняя, поскольку никому не требуется перепрыгнуть на него из общего сценария. А вот ссылка «пакетная печать документов на груз» важна – она ведет на сценарий использования, формально описывающий действия пользователя и системы. Наши сценарии использования имели следующий формат:

  • Заголовок со следующими полями: • статус (В работе | Готов к рецензированию | Согласован) • пользователи (по описанию бизнес-ролей) • цель • предусловия • гарантированный исход • успешный исход • ссылка на описание пользовательского интерфейса (разработанного проектировщиком интерфейсов) • ссылка на сценарий тестирования (заполнялось тестировщиками)
  • Основной сценарий
  • Расширения сценария

Сценарии использования

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

Источник: https://habr.com/post/245625/

Характеристика: случаи составления и правила оформления – Все о кадрах

Способы писать характеристику - базовые требования к содержанию

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

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

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

Понятие характеристики. Виды

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

Чаще всего характеристика требуется, когда в отношении работника нужно принять какое-либо решение (наказать, поощрить, наградить и пр.), а также при запросах различных органов — ГИБДД, МИД, судов, военкоматов и др. В связи с этим характеристики делятся на внутренние и внешние.

Кроме того, характеристика может быть:

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

— служебной (составляется по запросу вышестоящего начальства при решении вопросов о переводе, применении мер поощрения или взыскания);

— аттестационной (составляется при проведении мероприятий по аттестации работников и представляется в аттестационную комиссию).

Бывает, что за характеристикой обращается бывший работник, которому этот документ необходим для трудоустройства на новое место. Например, на основании ст. 5 Закона РФ от 26.06.

1992 N 3132-1 “О статусе судей в Российской Федерации” претендент на должность судьи должен предоставить характеристики с мест работы (службы) за последние пять лет трудового (служебного) стажа, а в случае работы (службы) в течение указанного срока (полностью или частично) не по юридической специальности также с мест работы (службы) по юридической специальности.

Как видим, характеристики разнообразны. От вида зависит их содержание.

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

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

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

характеристики

Текст характеристики условно можно разделить на несколько блоков.

1. Заголовочная часть. Здесь указываются наименование документа и фамилия, имя, отчество сотрудника, на которого она составляется. На практике нередко в данной части указываются год рождения и наименование должности сотрудника: “Характеристика на главного специалиста отдела камеральных проверок Золотову Маргариту Владимировну 1978 года рождения”.

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

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

В этот же блок можно включить сведения о семейном положении — состоянии в браке, наличии детей и т.д.

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

До поступления в МОУ СОШ N33 сменила два места работы: МДОУ “Детский сад “Улыбка” (2005-2008), работала воспитателем в МОУ СОШ N 12 г. Саратов (2008-2012) учителем начальных классов. Характеристика с последнего места работы положительная.В 2012 году поступила в МОУ СОШ N 33. Работает в должности преподавателя начальных классов. Комарова П.Р. ведет активную работу по дополнительному образованию, ее ученики участвуют и побеждают в олимпиадах и других творческих мероприятиях, жалобы родителей на нее отсутствуют.

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

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

За время работы Шаров И.Д. проявил себя как высококвалифицированный специалист в области кадрового делопроизводства, хорошо знающий трудовое законодательство.К исполнению должностных обязанностей относится добросовестно и ответственно. Дисциплинирован. При решении сложных вопросов проявляет самостоятельность и оперативность.Обладает организаторскими способностями, пользуется авторитетом у коллег и сотрудников смежных подразделений.

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

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

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

Компетентность:

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

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

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

Успешно сочетает работу с самообразованием по своей специальности.

Часто высказывает собственное мнение даже по таким вопросам, в которых не очень хорошо разбирается.

Работоспособность:

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

К своей работе относится добросовестно (равнодушно). В работе показывает высокую (достаточную, недостаточную) интенсивность. Не любит свою работу, но выполняет ее добросовестно.

Организованность:

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

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

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

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

Для оценки личностных качеств можно использовать следующие фразы:

Умеет располагать к себе и находить с людьми общий язык.

Не всегда умеет избежать конфликтов, но своим поведением не дает повода к ссорам в коллективе.

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

В быту ведет себя скромно, отличается моральной устойчивостью.

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

Критику в свой адрес воспринимает правильно, немедленно принимает меры к устранению недостатков.

К сведению. Если у работника есть какие-то недостатки, они должны быть отражены в характеристике. Полностью положительный отзыв может вызвать сомнения в объективности этого документа. Оптимальное соотношение недостатков и положительных качеств составляет 1:5.

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

4. Иные сведения. В характеристике иногда приводятся и иные сведения о работнике, например, о его общественной деятельности.

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

В конце характеристики обычно пишут, для каких целей она выдается, например: “Настоящая характеристика выдана для предъявления в Автозаводский районный суд г. Нижнего Новгорода”. Если документ будет отправлен в несколько мест, можно отметить, что характеристика выдается для предъявления по месту требования.

Оформляем и выдаем характеристику

Какой-то унифицированной формы для характеристики законодательно не установлено, поэтому она оформляется произвольно на листах формата А4. Текст излагается от третьего лица, с использованием глаголов настоящего или прошедшего времени (окончил, работал, выполняет, имеет и пр.).

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

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

Обратите внимание! Поскольку характеристика — документ, содержащий персональные данные работника, при ее составлении необходимо учитывать требования гл. 14 ТК РФ.

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

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

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

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

Подведем итог

Обобщим все вышесказанное — дадим краткий инструктаж по составлению характеристики.

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

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

Затем опишите трудовую деятельность до того, как работник поступил к вам.

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

Помните о целях составления характеристики и оценивайте деловые и личностные качества кратко и точно.

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

подала апелляцию, результатом которой стало сокращение срока отбывания наказания. Свою позицию апелляционная инстанция обосновала наличием смягчающих обстоятельств — явки с повинной, положительных характеристик С. с места жительства и работы (Определение Московского городского суда от 20.05.

2013 по делу N 10-3077/13).

Источник: http://info-personal.ru/jformlenye-dokymentov/harakteristika-sluchai-sostavleniya-i-pravila-oformleniya/

Структура научной статьи

Способы писать характеристику - базовые требования к содержанию

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

  1. Название (заголовок).
  2. Аннотация.
  3. Ключевые слова.
  4. Введение.
  5. Обзор литературы.
  6. Основная часть (методология, результаты).
  7. Выводы и дальнейшие перспективы исследования.
  8. Список литературы.

Рассмотрим особенности составных элементов научной статьи и основные требования, которые необходимо соблюдать при работе над ними.

Название

Название (заголовок) — обозначение структурной части основно­го текста произведения (раздела, главы, параграфа, таблицы и др.) или издания.

Основное требование к названию статьи — краткость и ясность. Максимальная длина заголовка — 10—12 слов. Название долж­но быть содержательным, выразительным, отражать содержание статьи.

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

  1. Заглавие должно быть информативным.
  2. Название должно привлекать внимание читателя.
  3. В названии, как и во всей статье, следует строго придержи­ваться научного стиля речи.
  4. Оно должно четко отражать главную тему исследования и не вводить читателя в заблуждение относительно рассматриваемых в статье вопросов.
  5. В название должны быть включены некоторые из ключевых слов, отражающих суть статьи. Желательно, чтобы они стояли в нача­ле заголовка.
  6. В заголовке можно использовать только общепринятые сокра­щения.

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

Аннотация

Аннотация — это не зависимый от статьи источник информации. Ее пишут после завершения работы над основным тек­стом статьи.

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

В ней указывают, что нового несет в себе данный документ в сравнении с другими, родст­венными по тематике и целевому назначению. Рекомендуемый объ­ем — 100 – 250 слов на русском и английском языках.

Аннотация выполняет следующие функции:

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

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

  1. Вступительное слово о теме исследования.
  2. Цель научного исследования.
  3. Описание научной и практической значимости работы.
  4. Описание методологии исследования.
  5. Основные результаты, выводы исследовательской работы.
  6. Ценность проведенного исследования (какой вклад данная работа внесла в соответствующую область знаний).
  7. Практическое значение итогов работы.

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

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

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

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

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

Сведения, содержащиеся в заглавии статьи, не должны повторяться в тексте авторского резюме.

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

ПРИМЕР АВТОРСКОГО РЕЗЮМЕ НА РУССКОМ ЯЗЫКЕ:

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

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

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

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

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

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

ЭТО ЖЕ АВТОРСКОЕ РЕЗЮМЕ НА АНГЛИЙСКОМ ЯЗЫКЕ:

A considerable part of innovative plans concerning implementation of developments with underlying novelties either do not reach the implementing stage, or in fact yield less benefit than anticipated. One of the reasons of such failures is the fact that the manager lacks real tools for planning, evaluating and controlling innovations.

The article brings forward the mechanism for a strategic planning of a company, the analysis of both inner company’s resources, and outer competitive strength, as well as on searching ways of using external opportunities with account taken of the company’s specific character.

Strategic planning is a code of regulations and procedures containing a series of methods, the use of which makes it possible for company’s manager to ensure prompt measures of reaction to outer business environment changes.

Such methods include: strategic segmentation; solving problems in real-time mode; diagnostics of strategic readiness to operate in the context of the future; working out a general plan of management; planning of the business position of the firm; strategic transformation of the company.

Strategic planning process is presented as a closed cycle consisting of 9 successive stages, each of them represents a logical sequence of measures ensuring the dynamics of system development.

The developed by the author strategic planning methods result in the recommendation to proceed to “interactive strategic management” which is conceptually the constructive potential of the collective body, on searching ways of its building on the basis of effective overcoming accelerating changes, increasing organizational complexity, and unpredictable changeability of the environment.

Ключевые слова

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

Введение

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

Далее необ­ходимо раскрыть теоретическую и практическую значимость работы и описать наиболее авторитетные и доступные для читателя публика­ции по рассматриваемой теме.

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

Во введении в обязательном порядке четко формулируются:

  1. цель и объект предпринятого автором исследования. Работа должна содержать определенную идею, ключевую мысль, раскрытию которой она посвящена. Чтобы сформулировать цель, необ­ходимо ответить на вопрос: «Что вы хотите создать в итоге проведен­ного исследования?» Этим итогом могут быть новая методика, клас­сификация, алгоритм, структура, новый вариант известной техноло­гии, методическая разработка и т. д. Формулировка цели любой рабо­ты, как правило, начинается с глаголов: выяснить, выявить, сформи­ровать, обосновать, проверить, определить и т. п. Объект — это ма­териал изучения.
  2. актуальность и новизна. Актуальность темы — степень ее важ­ности в данный момент и в данной ситуации. Это способность ре­зультатов работы быть применимыми для решения достаточно зна­чи­мых научно-практических задач. Новизна — это то, что отличает ре­зультат данной работы от результатов, полученных другими авто­рами.
  3. исходные гипотезы, если они существуют.

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

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

четко ли сформулированы цели, объект и исходные гипотезы, если они существуют;·

нет ли противоречий;·

указана ли актуальность и новизна работы;·

упомянуты ли основные исследования по данной теме.·

Обзор литературы

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

Основная часть

Методология

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

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

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

Результаты

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

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

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

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

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

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

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

https://www.youtube.com/watch?v=K8zkzyDZOQs

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

Заключение, выводы

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

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

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

Источник: https://journals.kantiana.ru/authors/imk/the_structure_of_scientific_articles/

HelpIcs
Добавить комментарий