Криптотрейдинг: прибыльная торговля криптовалютой.
Июн 9, 2019
31 Views
Комментарии к записи Жизненный цикл документа — DDLC отключены

Жизненный цикл документа — DDLC

Written by
Биткоин: краткое руководство

До сих пор вы читали жизненный цикл разработки программного обеспечения SDLC, циклический процесс в разработке программного обеспечения, который устанавливает порядок рабочего процесса, но сегодня еще один ребенок родился в блоке DDLC. Аббревиатура DDLC означает «цикл разработки документа», удивлен! Я уверен, что у вас должна была быть база данных Thought вместо Документа, но Документ абсолютно здесь.

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

o анализ требований

o Проектирование

o Разработка

o Тестирование

o Издательство

Для обслуживания

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

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

Здесь вам не просто нужно интервью с экспертами, писатель должен использовать программное обеспечение, чтобы получить подробную информацию о функциональности. Весь анализ должен быть написан в читаемом формате. Это будет очень полезно позже, и больше не нужно больше раундов МСП или разработчиков при документировании.

проектирование — Эта фаза очень важна, потому что она создает каркас документа. От титульного листа до сводки к оглавлению (TOC) до фактического текста, от словаря до индекса, здесь создается проект. Например, если вы используете Microsoft Word 2007, вам просто нужно поместить содержимое оглавления и указатель. Позже, когда вы напишите, эти таблицы будут обновлены, если вы нажмете опцию обновления.

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

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

Фаза разработки, хотя она и занимает центральное место, все еще сияет, когда она связана и сопоставлена ​​с остальными фазами точно так, как планировалось.

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

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

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

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

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

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

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

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

Прашант Шривастава

prashant @ friendstime

http://www.friendstime.com

Article Categories:
Криптовалюта
Как устроен блокчейн

Comments are closed.