Формат разработки что это такое
Документирование в разработке ПО
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 были написаны с должным старанием и правильно оформлены.
Я не буду подробно на них останавливаться, если вдруг тема заинтересует – расскажу о том, как их составление можно автоматизировать.
Как разработать свой формат электронного документа? Вопросы и ответы
Представители бизнеса, активно использующие ЭДО, заинтересованы в том, чтобы у документов появлялись электронные форматы. Методические рекомендации по их разработке недавно утвердили в ФНС. В статье расскажем, кому они будут полезны и как их применять на практике.
Для чего нужны методические рекомендации ФНС?
Раньше организации сами разрабатывали форматы электронных документов и спокойно пользовались ими. При этом поля и данные они именовали по-своему. Это негативно сказывалось на желании представителей бизнеса обмениваться документами — либо используем чей-то формат, либо продолжаем работать на бумаге.
Методические рекомендации от ФНС вводят единообразие на государственном уровне, регламентируют процесс разработки и сопровождения форматов.
Обязательны ли рекомендации для применения?
Нет, правила носят добровольный характер. Однако органы государственной власти будут принимать электронные документы, составленные по форматам, разработанным и введённым в действие в соответствии с указаниями ФНС. Если формат был создан и применяется без учёта правил, то всё зависит от решения соответствующего органа власти.
Что представляет собой справочник элементов форматов?
Для упрощения разработки форматов ФНС на своём сайте будет вести и публиковать электронный справочник унифицированных элементов электронных документов (далее — Справочник).
В Справочник войдут:
Справочник содержит следующую информацию: наименование элемента, его код, описание и другие данные. С полным списком можно ознакомиться в документе ФНС.
В Справочник также будут включаться новые элементы, использованные при описании вводимого в действие формата. ФНС будет обновлять его и размещать в течение 5 рабочих дней с даты регистрации документа в Министерстве юстиции Российской Федерации.
Как будет происходить планирование разработки формата?
Ожидается, что будет создана Комиссия по форматам электронных документов (далее — Комиссия) — экспертный орган, в состав которого приказом ФНС могут включаться представители органов власти, негосударственных организаций и Банка России. Вместе они займутся рассмотрением и урегулированием вопросов, связанных с планированием, разработкой, описанием, вводом в действие и прекращением действия форматов электронных документов.
Основываясь на результатах заседания Комиссии, ФНС будет утверждать план разработки и ввода в действие форматов электронных документов. Его будут создавать на основании предложений всех заинтересованных сторон. Форматы, по которым получено заключение Комиссии о их востребованности, будут иметь приоритетное значение.
План разработки и ввода в действие форматов электронных документов включает:
Допускается инициативное внесение на рассмотрение Комиссии своего разработанного формата. Его нужно направить официальным письмом в ФНС России. Там его рассмотрят в течение 2 месяцев и исправят, если посчитают это необходимым.
В чём особенности разработки формата электронного документа?
При создании нового формата необходимо опираться на бизнес-требования, включающие:
Бизнес-требования необходимо представлять в пакете документов совместно с форматом.
При формировании структуры нового документа нужно учитывать положения законодательства, нормативных правовых актов, стандартов и иных обязательных требований.
При разработке формата необходимо использовать исключительно элементы, указанные в Справочнике. При их отсутствии разработчик предлагает собственное описание необходимых элементов.
В свою очередь Комиссия может рассмотреть предложенные варианты и вынести следующее решение:
Знакомый бухгалтеру формат электронного счета-фактуры утверждается приказом ФНС. Данные инициативы в случае их одобрения также будут изданы официальным документом.
У Комиссии будет месяц на рассмотрение предложения. Какое решение может быть принято:
Указанные правила касаются как разработки форматов в соответствии с планом, так и при инициативном внесении форматов на рассмотрение Комиссии.
Как отслеживать начало и прекращение действия формата?
Формат электронного документа вводится в действие на основании:
Срок — не ранее чем через 5 месяцев с момента утверждения такого приказа. При этом должны быть рекомендации Комиссии о вводе его в действие.
Прекращение использования формата электронного документа происходит по согласованию с Комиссией по тем же основаниям.
На сайте ФНС будет размещен реестр утвержденных форматов электронных документов (далее — Реестр). Регламент обновления списка — 5 рабочих дней с даты регистрации нового формата.
Реестр будет содержать следующую информацию: идентификатор, наименование, версию формата и т. д.
Ожидания бизнеса
Ждал ли бизнес рекомендации от ФНС? Конечно, да. Известно много случаев, когда, не обнаружив необходимый формат электронного документа, представители бизнеса разрабатывали его самостоятельно. При этом вопросов было очень много. Надеемся, что методические рекомендации от ФНС помогут бизнесу и послужат хорошим стимулом для дальнейшей генерации новых форматов.
Единые форматы электронных документов чаще всего нужны в бухгалтерии — для быстрого взаимодействия с контрагентами. Чтобы ускорить процессы, также можно подключить интеллектуальные сервисы или организовать электронный архив. Но и это ещё не всё. Больше возможностей — в цифровой бухгалтерии от Directum.
Форматы и формы электронных документов. В чем разница?
Вопросы о том, чем отличается форма электронного документа от формата, появились с тех самых пор, когда Федеральная налоговая служба дала добро на использование в налоговом учете электронных первичных документов. Произошло это более трех лет назад. Тем не менее, данные понятия путают до сих пор. Давайте разбираться, что есть что.
Ваша компания до сих пор обменивается бумажными документами?
Что такое форматы электронных документов?
Чтобы ответить на этот вопрос, начнем с небольшой классификации. Весь перечень документов, используемых сегодня в организациях, можно разделить на две группы:
В данном случае нам интересны документы первой группы, которые по законодательству разрешено создавать, передавать и хранить в электронном виде. Правда, стоит иметь в виду, что к форматам некоторых электронных документов закон предъявляет жесткие требования, равно как и к форме ряда электронных документов.
.XML – единый формат учетных документов
Все электронные документы (далее – ЭД), которые применяет ваша организация в работе, делятся на формализованные и неформализованные.
ЭД, формат которых четко описан и определен законодательством, называются формализованными. К ним относятся: счет-фактура, накладная ТОРГ-12 и акт выполненных работ.
Все остальные ЭД (счета на оплату, письма, доверенности, паспорта сделки и др.) являются неформализованными. Особых требований к их форматам не существует. Форма данных электронных документов так же не важна.
Форма электронного документа – не есть его формат
Шаг за шагом мы приближаемся к пониманию того, что представляет собой формат электронного документа. На самом деле определений данного понятия может быть несколько. Это и структурированный набор данных, удобный для хранения и автоматической обработки. Форматом можно назвать и закодированную текстовую информацию, которая отвечает за распределение и представление данных в ЭД.
Теперь перейдем к форме. Если формат отвечает за «внутреннее содержание», то форма электронного документа являет собой его «лицо». Другими словами, то, как выглядит ЭД на экране компьютера или на бумаге, и есть его форма. Для некоторых документов закон определяет жесткую форму. Это в первую очередь касается счета-фактуры, форма которого утверждена Постановлением Правительства РФ от 26 декабря 2011 г. N 1137.
Обязательные и рекомендованные форматы и формы электронных документов
Итак, давайте сделаем выводы. Среди всего массива форм и форматов существуют обязательные к применению и рекомендованные. Чтобы раз и навсегда уяснить положение дел с формами и форматами электронных документов, просто ознакомьтесь со следующей таблицей.
Таблица 1. Обязательные и рекомендованные форматы и формы электронных документов
Автор: Герасимова Евгения, PR-специалист Synerdocs
Что такое разработка проектной документации и что в неё входит
Разработка проектной документации: что это
Перед началом разработки проектной документации, необходимо знать, что это такое. Вообще, сама по себе, проектная или проектно-сметная документация, как её ещё называют – это перечень документов, в которых отражается вся структура проекта. Его цели, задачи, возможные трудности и пути их решения. В принципе, сам процесс составления можно сравнить с техническим заданием на создание сайта, так как в нём будет так же подробно описываться любая мелочь.
Разработка проектной документации – это один из главных этапов реализации проекта. В них отражаются не только расчёты, которые приведены в виде графиков и формул, но и различные решения сложностей на пути воплощения проекта в полномасштабный объём. Важную роль сметные документы играют в проектировании строительства какого-либо объекта, особенно, если речь идёт о масштабных построениях.
Ведь, чтобы верно рассчитать все параметры здания, расположить его в таком месте, чтобы природные и климатические условия не наносили сооружению ущерб, необходимо всё это сначала проработать на бумаге. Это всё равно что составить бизнес-план, то есть с помощью наглядного примера выявить проблемную область и разработать пути решения.
Кто занимается разработкой проектной документации
Не многие представляют, кто и где занимается разработкой проектной документации. На самом деле, на этот вопрос есть два ответа. Первый, это когда сами участники-разработчики своими силами, читая литературу про экономику и черчение, пытаются составить смету, сделать графические чертежи намеченного продукта. Во втором случае, эта работа предоставляется профессионалам.
Да, есть специальные агентства, или отдельный, специально обученный человек, который профессионально занимается составлением смет, сводкой данных и черчением модели готового продукта, который получится в итоге. На самом деле, подобное занятие – это сложный процесс, именно поэтому такая услуга стоит недёшево, если говорить конкретно, то цены SEO продвижение сайтов в месяц не на много выше, чем стоимость разработки документов для проекта.
Конечно, в обращении к специалистам есть своим плюсы. Во-первых, это сокращение времени, которые может уйти на обучение всем тонкостям расчётов и умение составлять чертёж. Так же, документация будет разработана максимально точно, что позволит избежать просчётов, которые в последствии могут стать роковой ошибкой. Для тех, кто выделил на создание самого проекта конкретную сумму, может себе это позволить, тем самым повысить вероятность в том, как получить финансирование проекта, и компенсировать свои затраты.
Что входит в разработку проектной документации
Всё, что входит в разработку проектной документации, прописано в соответствующем документе, а точнее, в Постановлении Правительства РФ от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требования к их содержанию». Согласно этим требованиям, в составе проектных документов должно присутствовать две части: текстовая и графическая.
В текстовой части должно содержаться всё, что касается объекта, то есть основные сведения Это и подробное описание процесса разработки, и приложения в виде нормативно-правовых актов, регламентов и гостов, а так же пояснительные записки и сама смета. Так же, в рамках теоретической части будут описаны различные проектные решения, связанные с размещения объекта, так же затрат на оборудование и возможные дополнительные инвестирования в проект.
К графическому материалу, относятся чертежи, содержащие наглядное конструирования концептуальных моделей, с помощью которых и выявляют проблемные области и анализируют сущность объекта. Вместе с чертежом, как правило, прилагается пояснительная записка, содержащая описание анализа, которое обосновывает принятия различных архитектурных решений. В ней так же описываются меры безопасности работ, которые будут проводиться в рамках реализации проекта.
Так же, своеобразным дополнением в проектной документации присутствует ещё и экономическая часть. Логично догадаться, что она будет содержать все расчёты, связанные с затратами на проект, а так же обосновывающее описание, по которому нужно будет производить финансирование и дальнейшее инвестирование.
На самом деле, разработка проектной документации – долгий и кропотливый процесс. Его основная цель – максимально точно представить макет проекта, точнее объекта проектирования, рассчитать все финансовые затраты, а так же обосновать решения, связанные с проектированием и конструированием той или иной модели.
Ответственный за составление документов проекта берёт на себя огромную ответственность за весь процесс реализации. Так как, в отличие от специалиста по продвижению сайта в топ 3 Яндекса, разработчик проектной документации отвечает за безопасность, надёжность и конструктивность всего процесса.
файл разработки ПО
3.76 файл разработки ПО: Сохраняемая совокупность данных, необходимых для разработки конкретного ПО. Содержит обычно (либо непосредственно, либо путем ссылок) сведения, связанные с анализом требований, проектированием и реализацией; информацию о тестировании, проводимом разработчиком, а также план и информацию о состоянии разработки.
Смотреть что такое «файл разработки ПО» в других словарях:
файл — 01.01.38 файл [ file]: Поименованная совокупность записей, рассматриваемая как единое целое. [ИСО/МЭК 2382 4:1999, 04.07.10] Примечание Файлы хранятся в компьютере, мобильном терминале данных или в системе управления информацией. Источник … Словарь-справочник терминов нормативно-технической документации
Файл-сервер — Файловый сервер это выделенный сервер, оптимизированный для выполнения файловых операций ввода вывода. Предназначен для хранения файлов любого типа. Как правило, обладает большим объемом дискового пространства. Для повышения надежности хранения… … Википедия
Файл-серверная СУБД — Система управления базами данных (СУБД) специализированная программа (чаще комплекс программ), предназначенная для организации и ведения базы данных. Для создания и управления информационной системой СУБД необходима в той же степени, как для… … Википедия
РД 34.35.129-95: Рекомендации. Порядок разработки и поставки программных изделий к персональным ЭВМ для типовых задач тепловых электростанций — Терминология РД 34.35.129 95: Рекомендации. Порядок разработки и поставки программных изделий к персональным ЭВМ для типовых задач тепловых электростанций: 3.2. Определения ПРОГРАММНОЕ СРЕДСТВО программа, снабженная комплектом программных… … Словарь-справочник терминов нормативно-технической документации
ГОСТ Р 51904-2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию — Терминология ГОСТ Р 51904 2002: Программное обеспечение встроенных систем. Общие требования к разработке и документированию оригинал документа: 3.1 алгоритм: Конечное множество четко определенных правил, которые задают последовательность действий … Словарь-справочник терминов нормативно-технической документации
Файловый сервер — Файл сервер это выделенный сервер, предназначенный для выполнения файловых операций ввода вывода и хранящий файлы любого типа. Как правило, обладает большим объемом дискового пространства, реализованном в форме RAID массива для обеспечения… … Википедия
NVIDIA Ion — Файл:Ion.jpg Внешний вид системы ION NVIDIA Ion система для разработки на её базе PC совместимых компьютеров, включающая в себя чипсет NVIDIA GeForce 9400M и процессор Intel Atom. Чипсет содержит всего одну микросхему, что упрощает схемотехнику… … Википедия
SNES — Super Nintendo Entertainment System Производитель Тип Игровая пр … Википедия
Satellaview — Super Nintendo Entertainment System Производитель Тип Игровая пр … Википедия
Snes — Super Nintendo Entertainment System Производитель Тип Игровая пр … Википедия