Как называется текстовый документ проекта
Документирование в разработке ПО
INTRO
Добрый день, уважаемое сообщество.
Позвольте представиться. Я бизнес-аналитик, уже десять лет работаю в области разработки заказного программного обеспечения, в последнее время совмещаю роли аналитика и руководителя проектов.
Одним из болезненных вопросов в разработке ПО всегда был и остаётся процесс документирования этой самой разработки. Вам доводилось приходить на проект, который делают уже пару лет, но, при этом, вы никак не можете с ним разобраться, потому что из документов есть одно техническое задание, да и то написано в самом начале и не отражает и половины функционала системы? Мне доводилось. И это, честно говоря, очень печальное и байтораздирающее зрелище.
Поэтому на всех своих проектах я стараюсь изначально построить процесс так, чтобы неопознанного и неописанного функционала не было, все члены команды вовремя получали актуальную информацию и вообще был мир во всём
Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.
1. Документация обеспечивает «общее пространство» проекта. Любой участник в любой момент времени может получить необходимую информацию как по конкретной задаче, так и по общему направлению работы.
2. Команда говорит «на одном языке» — ведь гораздо проще понять человека, сообщающего «об ошибке в функции, описанной в Use Case №12», чем «о стрёмном баге в той фигне, которую Вася месяц назад делал».
3. Документирование позволяет четко разграничить зоны ответственности между участниками проекта.
4. Только тщательно описанные требования могут быть проверены на полноту и непротиворечивость. «Наколенные записки» — прямой и очень быстрый путь к тому, что границы проекта расползутся резвыми тараканами, а функционал, задуманный вначале, не будет монтироваться с возникающими в процессе «хотелками» заказчика.
Для себя я выработала набор базовых правил, которые позволяют эффективно документировать, планировать и контролировать разработку в комфортных для всех участников условиях.
1. Документация не должна быть избыточной и объемной. Мы пишем документы не за-ради приятного процесса постукивания по клавишам, а для того, чтобы их использовать в работе. Избыточное количество текста – раздражает и затрудняет восприятие.
2. Вся схема документирования проекта должна быть взаимоувязанной и логичной. Если в схеме существует документ, который не связан ссылкой с каким бы то ни было другим документом, то его можно безболезненно из схемы исключить.
3. Вся оценка трудозатрат должна производиться только на основании описанных атомарных задач. Сложно оценить разработку «функционала подсистемы ввода данных», гораздо проще оценить задачи «разработка формы ввода данных марсиан» и «разработка фильтра списка марсиан». Чем мельче оцениваемый элемент – тем точнее будет агрегированная оценка.
4. Всегда необходимо формировать списки оповещения заинтересованных участников. Разработчик, узнающий о необходимости доработки за три дня до релиза – это зло и подлейшая подлость, аналитик, втихаря поменявший требования и не уведомивший всех заинтересованных участников о необходимости доработки – последняя свинья, а РП, допустивший такую ситуацию – чума, холера и неприятный человек, который не справляется со своими обязанностями.
Я предлагаю на суд уважаемого сообщества схему документирования, которая кажется мне удобной, логичной и правильной. И – да, это работает.
Итак, какие типы документов используются в схеме.
1. Техническое задание.
2. Частное техническое задание (опционально).
3. Сценарий использования (Use Case).
4. Сценарий тестирования (Test Case).
5. Отчет об ошибке (Bug Report).
6. Руководство пользователя.
7. Руководство администратора (опционально).
На рисунке ниже — схема связи между этими документами. 
Изначально, при обследовании, формируется Большое Техническое задание.
Оно включает в себя:
• словарь терминов предметной области;
• описание предметной области;
• описание ролевой системы;
• описание функциональных требований;
• описание нефункциональных требований.
Описание требований в этом документе фиксируется на «верхнем уровне», то есть мы описываем не конкретные действия, а только необходимые функции. Требования оптимально разбивать на смысловые группы по подсистемам.
Например, мы описываем подсистему «Администрирование» с функциями «Создание карточки пользователя», «Удаление карточки пользователя», «Редактирование карточки пользователя». Это требования верхнего уровня, ниже в ТЗ опускаться смысла нет.
В случае, если система большая, разумно сделать Частные технические задания на каждую подсистему.
ЧТЗ должны содержать:
• ссылку на пункт ТЗ;
• максимально подробную информацию по каждой функции;
• список UseCases для функции.
Таким образом реализуется преемственность документов, что позволяет, во-первых, унифицировать их форму, во-вторых – частично реализовать повторное использование, то есть снизить затраты времени на «писанину».
Например, мы формируем ЧТЗ на всё ту же подсистему «Администрирование». Оно будет содержать описание функции: «Создание карточки. Необходимо реализовать следующий функционал: вызов карточки посредством кнопки «Создать», интерфейс карточки, содержащий следующий набор полей, сохранение карточки посредством кнопки «Сохранить», отмену сохранения посредством кнопки «Отмена»».
Use Case
Use Case — суть вариант использования, он описывает все действия, которые пользователь может произвести, и реакцию системы на эти действия.
Каждый Use Case должен быть привязан к пункту ЧТЗ.
Наиболее оптимальным, на мой взгляд, является формат описания, включающий в себя:
• Макет экрана. Макеты можно делать и сложные, «кликабельные», но, по опыту, хватает «проволочной диаграммы», сделанной с помощью Visio или аналогичного инструмента. Если на форме предполагается использование модальных окон, то они тоже должны быть прорисованы, нижеописанные таблицы для них должны дублироваться.
• Диаграмму действий экрана, в графическом виде описывающую алгоритм работы функции.
• Таблицу с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
• Таблицу с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
Также возможно небольшое общее описание функционала но, как правило, оно просто не нужно.
Test Case
Test Case, что вполне самоочевидно, должен содержать описание тестовых сценариев.
В идеале, каждый такой документ привязывается к соответствующему Use Case, но бывает так, что логично объединить несколько Use Cases в один Test Case.
Оптимальным вариантом формата описания является таблица, содержащая в одном столбце описание атомарной операции, влекущей ответное действие системы, во втором – описание правильной реакции системы. Описывать, к примеру, процесс ввода текста в текстовое поле не нужно, а вот проверку валидности данных при сохранении (щелчке по кнопке «Сохранить») – обязательно.
Bug Report
Ещё немного побуду кэпом: Bug Report возникает в процессе тестирования системы как реакция тестировщика на ошибку. Каждый документ должен обязательно ссылаться на соответствующий Test Case.
Содержать документ должен:
• скриншот возникшей ошибки;
• описание предшествующих действий. Лучше всего разработать удобный для всех шаблон такого описания – это сильно экономит время разработчикам при воспроизведении бага;
• текстовое описание самой ошибки.
Руководство пользователя/Руководство администратора
Самые занудные в написании, но, тем не менее, жизненно необходимые документы.
По сути, их формирование можно даже автоматизировать, если все Test Cases и Use Cases были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.
Документация в порядке
Пост о том, зачем и как аккуратно вести проектную документацию, даже если у вас Agile. Делюсь перечнем и структурой полезных документов и рекомендациями по работе с ними.
Речь пойдет в основном о внутренних документах, которые обычно никто не просит писать, но которые на самом деле нужны команде.
Небольшое лирическое отступление про то, что меня вдохновило на написание этого текста:
Теория разбитых окон
Считаю, что принцип теории можно распространить практически на все сферы жизни человека: чистота и порядок провоцируют на созидание и продуктивность, убирают элементы хаоса и отвлекающие факторы. Однако, конечно, лучше оставлять пространство для творчества и не сковывать себя абсолютной “идеальностью”.
Зачем писать
Что писать
Сложно представить проект, на котором документация не нужна совсем. Другой вопрос, что она может быть разного формата и в разных объемах, покрывать разные аспекты системы.
Легче кому-то одному потратить пару часов на документирование, чем всей команде постоянно проверять свою память.
Необходимый минимум
На мой взгляд документы, которые важны практически на любом проекте, это:
Документ-маршрутизатор
Артефакты проектных процессов
Флоу процесса разработки, статусная модель задач, доски с беклогом, план-график проекта, список нужных контактов и пр. Наличие такой документации налаживает процесс работы и делает его более комфортным. А также сильно разгружает аналитика/менеджера/тимлида и всех, кого волнует выполнение задач и сроки.
Глоссарий
Приводит всех участников работ к одному понятийному полю. Особенно полезен там, где много специальных терминов или разночтений. На некоторых проектах достаточно всего нескольких определений, но полезно все же их зафиксировать.
Артефакты бизнес-потребности и бизнес-процесса
Концептуальная модель системы
Описание основных сущностей, верхнеуровневая функциональность и взаимодействие с другими системами.
Пример верхнеуровнего описания процесса
Классы пользователей и уровни доступа
Cценарии использования
Логика работы системы
По коду или БД не всегда получается понять смысл функционала. Например, формула расчета стоимости скорее всего задается бизнес-правилами, о которых коду ничего не известно.
Описание АПИ
Тестовые данные
Среды, учетные записи и все, что нужно, чтобы не сводить с ума тестировщика однообразными вопросами.
Ограничения/нефункциональные требования
Другие типы документов
Потребность в некоторых документах возникает вариативно, в зависимости от особенностей проекта:
Архитектура системы
Иногда необходимо детальное описание сервисов и их взаимодействия. Например, если сервисов несколько и они взаимосвязаны, или если архитектура микросервисная.
Требования к данным
UX/UI макеты и прототипы
Их лучше сразу собирать в одном известном всем месте и держать в актуальном состоянии.
С чехардой в макетах разбираться потом очень сложно. Просто представьте, что у вас хотя бы 3 экрана и у каждого хотя бы по 5 состояний. И аналитик, дизайнер и разработчики смотрят каждый в свой проект в фигме.
Описание интеграций
Протоколы интеграций, спецификации АПИ, процессы и потоки данных и всё, что необходимо для избежания недоразумений при взаимодействии с другими системами.
Безопасность
В целом параметры безопасности могут быть описаны вместе с доступами или нефункциональными требованиями, либо же наследоваться от общего контура ИТ компании. Но бывают системы с приоритетом или особым подходом к этой характеристике.
Внешняя документация
Документы для пользователей, партнеров, надзорных органов и прочие артефакты, которыми система общается с внешним миром.
Как писать
Несколько инсайтов о работе с документацией:
Не забывайте про актуальность
Стоит писать только ту документацию, которую вы сможете поддерживать в актуальном состоянии.
Удобно складывать в одно место те артефакты, которые нет возможности обработать и хорошо оформить.
Растите культуру документирования в команде
Не обязательно всё должен документировать один человек, особенно если в команде нет специальной роли для этого. Даже не технические писатели умеют складывать ссылки в нужное место, писать чек-листы, комментировать макеты и прочее.
Важно договориться, как такая документация будет поддерживаться.
Комментарии в коде не всегда спасают
Структура кода не обязана повторять структуру процесса/функционала и, тем более, бизнес- и пользовательских требований. Поэтому из кода можно понять «как» работает система, но на вопросы «зачем?», «почему?» и «как должна?» отвечает именно проектная документация.
Планируйте и декомпозируйте работу с документацией
Когда-то я бронировала в календаре последние 2 часа пятницы на составление/актуализацию документации. Принимать решения в это время опасно, к тому же эта деятельность помогает подвести итоги рабочей недели и запланировать следующую.
Закрывайте техдолг
При введении функционала в эксплуатацию важно выделить время на дооформление хвостов. Иначе не видать спокойной поддержки и доработки системы.
Понять, чего не хватает, просто: представьте, что вы приходите на этот проект сейчас, и никто из предыдущей команды с вами поговорить не может.
Больше схем и диаграмм
Поможет изучение графических нотаций и UML, практика их применения, а также замечательная книга «Говори на языке диаграмм».
Учитесь писать нехудожественные тексты
Навык написания текстов сильно ускоряет процесс документирования и повышает его качество. Рекомендую использовать https://glvrd.ru. Плюс по возможности почитать «Пиши, сокращай» и «Бизнес-копирайтинг». Так и работа быстрее пойдет, и тексты станут понятнее и приятнее.
Как итог
Но важно знать, какие есть инструменты и практики и как это делают в идеальном мире. Тогда вы поймете, на чем основывать свою работу, чтобы не изобретать велосипед и не напарываться на издревле известные грабли.
29.Текстовые документы
В различных словарях можно найти следующие толкования понятия «текст»:
1) упорядоченный набор слов, предназначенный для того, чтобы выразить некий смысл;
2) всякая записанная речь (литературное произведение, сочинение, документ ит. п., а также часть, отрывок из них);
3) последовательность языковых и иных знаков, образующая единое целое, служащее объектом изучения.
С позиции информатики, текст — это последовательность знаков некоторого алфавита.
Вам известно, что в памяти компьютера тексты представляются в двоичном коде: 1) за каждым символом алфавита закрепляется определённый двоичный код; 2) в двоичном коде представляется и информация о типе и размере используемого шрифта, положении строк, полей, отступов и прочая дополнительная информация.
Практически в любой профессиональной деятельности работник сталкивается с необходимостью подготовки текстовых документов различного назначения и объёма: от заявления о приёме на работу до составления отчёта по результатам проделанной работы.
Можно выделить следующие виды текстовых документов:
Для каждой из перечисленных разновидностей текстовых документов существует определённый набор правил, которых следует придерживаться при работе над ними. Личное письмо отличается по стилистике от официального документа, а художественное произведение — от научного текста. Различаются также словари наиболее употребляемых слов и терминов для перечисленных разновидностей документов.
Дайте характеристику каждому из видов текстовых документов — художественному тексту, научному тексту, деловому документу, рекламному документу, личному документу.
Виды программного обеспечения для обработки текстовой информации
Существует множество программных продуктов, предназначенных для работы с текстовой информацией. Представим классификацию этой разновидности прикладного программного обеспечения по его назначению.
Текстовые редакторы — это программы, которые помогают подготовить текст простой структуры, но не обладают необходимыми средствами оформления его для печати. Типичный пример — редактор Блокнот (в ОС Windows).
Текстовые процессоры — более сложные программные комплексы, позволяющие выполнить оформление текста, точно задать его расположение, включить в него графические материалы. Примеры — Microsoft Word, OpenOffice Writer.
Специальные программные средства для подготовки научных текстов, содержащих математические, химические или другие формулы, сложные схемы и специфические обозначения, используемые в научных, учебных и технических публикациях и документах. При подготовке научных, технических и учебных текстов часто используется свободно доступная система подготовки публикаций ТEХ.
Издательские системы — комплексы программных средств, позволяющих выполнить весь цикл допечатной подготовки издания: импорт или набор текста, его оформление и расположение на листах, вставку иллюстраций и сложных объектов, и в итоге — вывод издания на печать. Примерами таких программ могут быть пакеты Adobe InDesign, Scribus, QuarkXPress. Процесс и результат создания страниц издания называют вёрсткой, а точную копию самого издания — оригинал-макетом. Использование издательских систем позволило значительно сократить срок подготовки печатных изданий, снизить трудоёмкость этого процесса, значительно расширить творческие возможности дизайнеров печатных изданий.
Электронные переводчики и словари предназначены для автоматического перевода текстов с одного языка на другой, проверки правописания текстов на разных языках. Особым видом словарей являются тезаурусы — словари, в которых слова связываются на основе каких-либо лексических отношений (например, слова, являющиеся синонимами, антонимами и т. п.). Примеры — PROMT, ABBYY Lingvo.
Системы оптического распознавания текстов (например, ABBYY FineReader) предназначены для преобразования отсканированного графического изображения текстового документа в текстовый формат.
Кроме того, программы для работы с текстовой информацией интегрированы в системы программирования, а также являются частью HTML-редакторов, предназначенных для создания вебстраниц.
Создание текстовых документов на компьютере
При подготовке текстовых документов на компьютере используются три основные группы операций: ввод, редактирование, форматирование.
Операции ввода позволяют сформировать содержимое и первоначальный вид текстового документа и сохранить его в памяти компьютера. Ввод может осуществляться не только набором с помощью клавиатуры, но и путём сканирования бумажного оригинала и последующего перевода документа из графического формата в текстовый (распознавания).
Напомним основные правила ввода текстовых документов с помощью клавиатуры.
При вводе и редактировании текста полезно включать режим отображения скрытых символов — символов, которые вводятся пользователем при наборе текста, но при печати не выводятся на бумагу, а на экране отображаются только при включении соответствующего режима (табл. 5.1). Режим отображения скрытых символов даёт возможность лучше понять структуру документа.
Для автоматизации ввода в современных текстовых процессорах существуют инструменты Автозамена и Автотекст.
Бывает, что при вводе текста с клавиатуры пользователь допускает опечатки: вместо нужной клавиши нажимает соседнюю, пропускает букву, меняет две буквы местами. Такие опечатки исправляются автоматически инструментом Автозамена, имеющим встроенный словарь наиболее типичных опечаток и ошибочных написаний.
Для быстрого ввода стандартных фраз по нескольким первым буквам можно использовать инструмент Автотекст. Он автоматически предлагает вставить короткую фразу из списка элементов автотекста, как только будут набраны несколько первых букв этой фразы.
Операции редактирования (правки) позволяют изменить уже существующий электронный документ путём добавления или удаления фрагментов, перестановки частей документа, слияния нескольких файлов, разбиения единого документа на несколько более мелких и т. д. (рис. 5.1)
На протяжении многих веков для внесения изменений в текст нужно было заново переписывать его. Основное преимущество компьютерной технологии создания текстовых документов заключается именно в удобстве его редактирования. Возможность быстро исправлять ошибки является одной из основных причин повсеместного перевода подготовки текстовой информации с бумажной на компьютерную основу.
23.3. Создание текстовых документов на компьютере
Ввод и редактирование при работе над текстом часто выполняются параллельно. При вводе и редактировании формируется содержание текстового документа.
Совокупность значений свойств объекта называют форматом объекта, а изменение этих значений — форматированием объекта.
Операции форматирования позволяют точно определить, как будет выглядеть текст на экране монитора или на бумаге после печати на принтере. Операции форматирования могут применяться как к отдельным объектам текстового документа (табл. 5.2), так и ко всему документу в целом. В первом случае говорят о прямом форматировании, во втором — о стилевом.
Такие действия по оформлению документа, как выравнивание абзацев, установка абзацных отступов и интервалов между абзацами, строками в абзацах и символами в словах и т. п., выполняются специальными средствами текстовых процессоров, а не вставкой пробелов и пустых строк.
Для облегчения анализа и последующего преобразования текста очень важно соблюдать основные правила его ввода, редактирования и форматирования.
В современных текстовых процессорах есть специальные инструменты, обеспечивающие автоматическую нумерацию страниц, таблиц и рисунков.
При работе с большими текстами, как правило, применяют стилевое форматирование. Смысл этой операции заключается в том, что структурным элементам, несущим одну и ту же функциональную нагрузку (например, заголовкам одного уровня, основному тексту, примерам и т. д.), назначается определённый стиль форматирования — набор параметров форматирования (шрифт, его начертание и размер, абзацные отступы, междустрочный интервал и др.).
Стиль — это имеющий имя набор значений свойств объектов каждого типа, входящих в текстовый документ.
В заключение приведём основные правила оформления текстов:
Средства автоматизации процесса создания документов
Мы рассмотрели основные операции ввода, редактирования и форматирования документов. Многие из них в той или иной мере направлены на автоматизацию процесса создания текстовых документов. Ещё больше возможностей в этом направлении обеспечивает использование шаблонов, макросов и средств, обеспечивающих работу со структурными компонентами документа.
Многие типовые документы должны иметь стандартный вид, который определяет, что и где размещается в создаваемом тексте, например: кому адресован документ, от кого он, дата создания документа и другие реквизиты.
Требования к оформлению, структуре и содержанию многих документов устанавливаются стандартами. Все они находятся в открытом доступе в Интернете.
Найдите в Интернете и познакомьтесь со следующими стандартами:
Какие из них имеют статус государственных, а какие — межгосударственных? Как это отражено в названии стандартов?
Что означают аббревиатуры ГОСТ, ЕСКД, СИБИД?
Какие из этих стандартов могут быть полезны в вашей учебной деятельности?
В текстовых процессорах есть шаблоны для создания документов разного типа.
Шаблон — это отформатированный определённым образом документ-заготовка, который хранится в отдельном файле и используется в качестве основы для создания новых документов определённого типа.
Пользователю достаточно ввести свою информацию в отдельные блоки шаблона, и она автоматически приобретёт заранее заданное оформление. В недалёком будущем каждому из вас для поиска подходящей работы придётся составить и разослать резюме. Подготовить его лучше всего с использованием соответствующего шаблона (рис. 5.2).
В текстовом процессоре Microsoft Word все шаблоны распределены на три группы:
1) установленные — шаблоны документов определённых типов (писем, факсов, отчётов и др.), которые инсталлированы на компьютере в составе пакета Microsoft Office;
2) Microsoft Office Online — шаблоны документов разнообразных типов (поздравительных открыток, визиток, бюллетеней, сертификатов, грамот, приглашений, заявлений, календарей и др.), которые расположены на веб-сайте Microsoft Office Online;
3) шаблоны пользователя — шаблоны, которые созданы пользователем.
23.4. Средства автоматизации процесса создания документов
При запуске программы Microsoft Word автоматически открывается шаблон Новый документ (файл Normal.dotm). При этом по умолчанию устанавливается формат (значения свойств) основных объектов документа — страницы, абзаца, символа, а также задаётся стилевое форматирование заголовков, списков, таблиц и др.
Запустите имеющийся в вашем распоряжении текстовый процессор. Исследуйте формат основных объектов документа в шаблоне Новый документ, выяснив для них значения свойств, приведённых ниже:
В процессе работы над документом в программе Microsoft Word часто приходится выполнять задания по некоторому алгоритму, состоящему из определённой последовательности действий. Например, подчеркнуть слова, написанные латинскими буквами, отформатировать какое-то слово во всём документе определённым образом и др.
Макрос — это последовательность команд, сгруппированных в одну макрокоманду, для автоматического выполнения определённого задания.
Основное назначение макроса состоит в том, чтобы освободить пользователя от многократного повторения однообразных действий во время обработки текстового документа, выполнить за него рутинную работу. Макрос создаётся один раз, сохраняется в шаблоне или документе и может многократно выполняться для автоматизации и ускорения обработки текстового документа.
Многостраничные документы (рефераты, брошюры, книги и т. п.) принято делить на структурные части — главы, параграфы, пункты ит. п., создавая таким образом иерархическую структуру документа. Рассмотрим в качестве примера структуру этого учебника. На верхнем (нулевом) уровне иерархии находится название документа («Информатика. 10 класс»); на первом уровне — названия глав, второй уровень составляют названия параграфов, третий — названия пунктов в параграфах, дальше размещается основной текст учебника.
Структура документа — это иерархическая схема размещения составных частей документа.
Использование в текстовом процессоре Microsoft Word специальных стилей с именами Заголовок 1, Заголовок 2 и т. д. даёт возможность автоматизировать создание иерархической структуры документа. В текстовом процессоре Microsoft Word для просмотра структуры документа используется режим просмотра Структура. В нём удобно редактировать иерархическую схему документа, изменяя с помощью специальных инструментов уровень текстовых фрагментов и последовательность их размещения.
Современные текстовые процессоры позволяют автоматически создавать оглавления документов, в которых к заголовкам разделов разных уровней применено стилевое форматирование. С помощью специальной команды пользователь указывает, заголовки каких уровней следует включить в оглавление, и абзацы указанных стилей автоматически выбираются из текста документа и помещаются с указанием номеров страниц, с которых они были взяты, в новый раздел «Оглавление».
Оглавление документа — это перечень названий структурных частей документа, упорядоченных в соответствии с его иерархической схемой, с указанием соответствующих номеров страниц
ГОСТ 7.32-2001 «СИБИД. Отчёт о научно-исследовательской работе. Структура и правила оформления»
Совместная работа над документом
Под совместной (коллективной) работой над документом принято понимать участие нескольких человек в создании одного текстового документа, при котором у каждого из них есть возможность отслеживать все изменения, сделанные в документе другими разработчиками, а также осуществлять возврат к одной из предыдущих версий документа.
На протяжении долгого времени процесс совместной работы над документом был устроен так: кто-то создавал текст на заданную тему, распечатывал его и отдавал другому человеку. Этот человек дописывал «от руки» свои вставки и комментарии и возвращал черновики на доработку. Такие итерации могли происходить неоднократно, в результате работа шла медленно, к тому же отдельные ценные мысли и идеи могли быть утеряны безвозвратно.
Современные инструменты создания текстовой информации предоставляют принципиально иные возможности для совместной работы над документом, поддерживая следующие варианты её организации.
1. Документ, над которым ведётся работа, можно сделать составным, объединяющим несколько других документов. Каждый разработчик создаёт и редактирует свою часть составного документа независимо от других, при этом в процессе работы он может просматривать текущую версию общего документа. Такой вариант организации совместной работы основывается на возможности создания мастер-документа, к которому могут прикрепляться другие документы.
2. Каждая из частей составного документа может редактироваться несколькими людьми. Для этого в современных текстовых процессорах предусмотрена возможность отслеживать и протоколировать сделанные изменения, делать примечания — пометки на полях.
Для отслеживания собственных исправлений, а также чтобы другие соавторы могли вносить изменения в документ, текстовый процессор предлагает использовать маркеры исправлений. Маркеры исправлений помогают увидеть, какие изменения были внесены в документ по сравнению с его последней версией. Для изображения исправлений используется специальный формат, например подчёркивание. С помощью маркеров исправлений можно сохранить запись о каждом сделанном исправлении и в дальнейшем либо принять его, либо отказаться. Исправление помечается полным именем его автора, датой и временем создания.
При совместной работе над документом важно, чтобы в настройках текстового процессора были указаны корректные данные о пользователе, т. к. именно они останутся в редактируемом документе.
Примечания — это обозначенные инициалами и пронумерованные комментарии, которые записываются и отображаются в специальном окне примечаний и не затрагивают текст документа. Перед тем как вставить примечание, имеет смысл выделить фрагмент текста, который следует прокомментировать. В этом случае при просмотре примечания текст, к которому оно относится, будет подсвечен.
Имеются возможности сравнения двух версий документов или объединения всех исправлений и примечаний в один документ, для просмотра их всех сразу. Сделанные в тексте изменения перед сохранением окончательной версии документа можно принять или отклонить.
Оба рассмотренных варианта организации совместной работы поддерживаются и в OpenOffice Writer, и в Microsoft Word.
3. Можно редактировать документ непосредственно в сети, также отслеживая все изменения, сделанные другими пользователями. Этот вариант поддерживается Google Docs — сетевым приложением, доступным через веб-браузер. Поскольку редактируемый документ сохраняется на сервере, он доступен всем пользователям, между которыми он разделяется. Каждый раз при сохранении документа сохраняется его новая версия и информация о том, кто этот документ редактировал. Команда просмотра изменений открывает список сделанных изменений с указанием, кто и когда их внёс. Различные версии документов можно сравнить между собой.
4. Можно использовать и промежуточный вариант, когда документ редактируется локально на компьютере, а храниться в сети и там же отслеживаются все изменения.
Оформление реферата как пример автоматизации процесса создания документов
Старшеклассники, студенты, курсанты в процессе своей учебной деятельности готовят рефераты по различным предметам.
Реферат — это самостоятельная исследовательская работа, в которой автор раскрывает суть исследуемой проблемы, приводит различные точки зрения, делает собственные выводы.
Выбрав тему реферата, необходимо определить цель работы, составить план (поставить задачи, определить порядок и сроки выполнения задач), найти и изучить материалы различных информационных источников, собрать и обработать информацию, сделать выводы, оценить полученные результаты.
Содержание реферата должно быть логичным, изложенным ясным языком. Основные положения реферата желательно подкреплять цитатами и ссылками на информационные источники.
Есть определённые требования и к оформлению реферата.
Реферат должен быть выполнен на одной стороне листов белой бумаги формата А4 (210 х 297 мм).
Размеры полей страницы (не менее):
Отступ первой строки: 8-12 мм, одинаковый по всему тексту.
Интервал междустрочный: полуторный.
Выравнивание абзаца: по ширине.
Гарнитура шрифта основного текста — Times New Roman или аналогичная.
Кегль (размер): 12-14 пунктов.
Цвет шрифта: чёрный.
Заголовки разделов и подразделов следует печатать на отдельной строке с прописной буквы без точки в конце, не подчёркивая. Если заголовок состоит из нескольких предложений, их разделяют точкой. Выравнивание по центру или по левому краю. Интервал: перед заголовком — 12 пунктов, после — 6 пунктов.
Страницы следует нумеровать арабскими цифрами, соблюдая сквозную нумерацию по всему тексту (титульный лист и оглавление включают в общую нумерацию). На титульном листе номер не проставляют.
В верхней части титульного листа пишется, в каком образовательном учреждении выполняется работа, далее буквами увеличенного кегля указывается тип («Реферат») и тема работы, ниже в правой половине листа — информация о тех, кто выполнил и кто проверит работу. В центре нижней части титульного листа пишется название населённого пункта и год выполнения работы.
Из курса русского языка вам известно, что цитата — это приведённое полностью или частично высказывание из авторского текста (научной, художественной, публицистической и др. литературы или доклада). Цитаты оформляются как прямая речь или как продолжение предложения.
Правовой статус цитирования определяется Гражданским кодексом РФ, согласно которому цитирование «допускается без согласия автора или иного правообладателя и без выплаты вознаграждения, но с обязательным указанием имени автора, произведение которого используется, и источника заимствования» (статья 1274 части 4 Гражданского кодекса РФ).
Допустим, при работе над рефератом вы взяли (заимствовали) информацию из источника «Андреева, Е. В. Математические основы информатики. Элективный курс: учебное пособие / Е. В. Андреева, Л. Л. Босова, И. Н. Фалина. — М.: БИНОМ. Лаборатория знаний, 2005». Необходимо правильно оформить ссылку на этот источник и внести его в список литературы.
Правила оформления ссылок регулируются ГОСТ Р 7.0.5-2008 «Система стандартов по информации, библиотечному и издательскому делу. Библиографическая ссылка. Общие требования и правила составления».
Правила оформления библиографических сведений в списке использованной литературы должны отвечать требованиям ГОСТ 7.12003 «Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления».
Для оформления ссылки в текстовом процессоре Microsoft Word можно:
1) установить курсор после заимствованного текста и выполнить команду Ссылки → Вставить ссылку → Добавить новый источник. ;
2) заполнить поля диалогового окна Создать источник (рис. 5.3);
3) затем щёлкнуть на кнопке ОК и после заимствованного фрагмента текста появится ссылка на источник в виде: «(Е. В. Андреева, 2005)».
Для оформления списка литературы в текстовом процессоре Microsoft Word можно:
1) выбрать стиль отображения списка литературы (библиографического списка), выполнив команду Ссылки → Стиль: → ГОСТ — сортировка по именам 2003;
2) выполнить команду Ссылки → Список литературы → Вставить список литературы.
Другие возможности автоматизации обработки текстовой информации
Компьютер помогает не только автоматизировать процесс создания текстовых документов, но и решить множество других задач, связанных с обработкой текстовой информации. Вот некоторые из них:
Область информатики, решающая эти и другие задачи, связанные с обработкой информации на естественном языке, называется компьютерной лингвистикой.
Рассмотрим более подробно задачу поиска текста в общем массиве. Существует несколько подходов к её решению.
Первый подход опирается на поиск фрагмента текста, соответствующего некоторому образцу. Таким способом в большом текстовом массиве можно находить упоминания тех или иных слов, адреса, номера телефонов и другие элементы. Основное достоинство такого подхода — возможность применять его к массиву текста без предварительной обработки (например, сразу при посимвольном получении текста). Применение рассматриваемого способа бывает затруднено, если текст хранится в разных местах.
Второй подход предусматривает предварительную обработку текста с целью получения его преобразованного, сокращённого вида (индекса). Получив запрос, поисковая система выделяет список слов и составляет список документов, в которых они содержатся. При этом рассчитывается релевантность — мера соответствия документа запросу, зависящая от наличия искомых слов, близости их друг к другу и других параметров. Документы с высокой релевантностью помещаются в начало списка, с низкой — в конец.
Одно из интересных применений автоматического анализа текстов — выявление заимствований.
Антиплагиат (antiplagiat.ru) — российский интернет-проект, программно-аппаратный комплекс для проверки текстовых документов на наличие заимствований из страниц сети Интернет и других источников. Проект доступен для всех пользователей.
Самое главное
Информационные технологии (ИТ) — это совокупность методов, производственных процессов, программно-технических и лингвистических средств, объединённых с целью сбора, обработки, хранения, распространения, отображения и использования информации, представленной в цифровой форме.
С позиции информатики, текст — это последовательность знаков некоторого алфавита. Существует множество программных продуктов, предназначенных для работы с текстовой информацией.
При подготовке текстовых документов на компьютере используются три основные группы операций: ввод, редактирование, форматирование.
Операции ввода позволяют сформировать содержимое и первоначальный вид текстового документа и сохранить его в памяти компьютера.
Операции редактирования (правки) позволяют изменить уже существующий электронный документ путём добавления, удаления, перестановки фрагментов, слияния нескольких файлов, разбиения единого документа на несколько более мелких и т. д.
Операции форматирования позволяют точно определить, как будет выглядеть текст на экране монитора или на бумаге после печати на принтере. Операции форматирования могут применяться как к отдельным объектам текстового документа, так и ко всему документу в целом.
Автоматизация процесса создания текстовых документов обеспечивается за счёт возможности работы с фрагментами, проверки правописания, стилевого форматирования, а также использования шаблонов, макросов и средств, обеспечивающих работу со структурными компонентами документа.
Компьютер помогает автоматизировать не только процесс создания текстовых документов, но и решить множество других задач, связанных с обработки текстовой информации, а именно: