Фт это что программа

Метод функциональных точек

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

Та блица!. Размер ФТ в числе строк исходного текста на ЯП

максимальное количество строк исходного текста ЯП на одну ФТ

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

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

Добавляем слова (тэги) в фото для продажи на стоках. С программой это делается элементарно.

Составление концептуальной модели ПО для оценки размеров ПО методом ФТ

Рис. 5 Схема проведения оценки размеров ПО по данным и транзакциям

Оценка программного продукта методом ФТ вырабатывается не на пустом месте — рассматриваются данные, которыми оперирует продукт, типы и количество его транзакций.- процессов преобразования данных (см. Рис. 5) [11].

К логическим данным оцениваемого программного продукта относятся:

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

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

Рассмотрим подробнее выполнение шагов метода ФТ[11].

• 1 .Количество функциональных точек в программе оценивается по количеству логических файлов групп данных внешних и внутренних ( RET) и уникальных полей данных в этих файлах (DET):

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

• — выходных данных из продукта на другие приложения,
• -количеству внутренних логических файлов.

.По количеству и структуре данных (RETh DET) производится оценка их «сложности» в соответствии с приведенными в методе таблицами (смотри приложение). В результате данные оцениваются как низкой, средней или высокой сложности. Оценки проводятся отдельно для внутренних файлов ILF и внешних файлов EIF.

Фотомонтаж — это просто. Как сделать фото монтаж. Графический редактор ГИМП (GIMP)

• 2. По проведенной оценки сложности данных определяется количество «не выровненных ФТ» (UFP) в соответствии со специальной таблицей., приведенной в методических материалах метода (смотри приложение).
• 3. Оценивается сложность транзакций. Транзакция переводит оцениваемый продукт из одного состояния в другое. Рассматриваются виды транзакций:

• — изменяет поведение продукта (тип EI),
• -поддерживает (управляет исполнением) внутренние файлы (тип EI),
• — представляет информацию пользователю (тип ЕО)).

В соответствии с этим рассматриваются виды транзакций

EI (external inputs) — внешние входные транзакции, элементарная операция управления, имеющиеся в интерфейсе ПО и приходящие извне, по обработке данных,

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

EQ (external inquiries) — внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

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

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

FTR (file type referenced) — позволяет подсчитать количество различных файлов (информационных объектов) типа ILF и/или EIF модифицируемых или считываемых в транзакции.

DET (data element type) — число неповторяемых уникальных полей данных. Примеры. EI: поле ввода, кнопка. ЕО: поля данных отчета, сообщений об ошибке. EQ: поля ввода для поиска, поля вывода результата поиска.

• 4. По проведенной оценке сложности транзакций оценивается количество «не выровненных ФТ» в соответствии с таблицей, приведённой в материалах метода, по типам транзакций (смотри приложение).
• 5. Проводится подсчет суммарного количества «не выровненных ФТ» UFP суммированием по всем информационным объектам данных и транзакций.
• 6. Помимо функциональных требований концептуальной модели ПО на оцениваемый программный продукт накладываются общесистемные требования, которые увеличивают сложность разработки. Для учета этой сложности применяется коэффициент выравнивания (VAF). Значение VAF зависит от 14 параметров Di, которые определяют системные характеристики оцениваемого программного продукта и приведены в специальной таблице ме- тода(смотри приложение), и принимают значения каждый в диапазоне 0-5:

Можно определить диапазон влияния факторов сложности на размер программного продукта, как диапазон изменения VAF, равный 0,65-1,35, т.е. более чем в 2раза. Таким образом, механизм выравнивания позволяет разработчику ПО учесть его возможные индивидуальные особенности.

7. Расчет окончательного количества «выровненных функциональных точек» (FP) продукта. Оценка количества выровненных функциональных точек для программы определяется путем умножения суммарного количества «невыровненных ФТ» UFP по п5 на «коэффициент выравнивания» VAF по следующей формуле:

8. Расчёт объёма программы в числе строк исходного кода на ЯП, проводится путём умножения определённого числа выровненных ФТ на размер одной ФТ на языке программирования из таблицы 1.

Глава З.Оценка трудоемкости программного проекта по его размеру Модели процесса разработки ПО и выбор адекватной модели.

Источник: bstudy.net

Не пишите ТЗ на проект 1С. Остановитесь!

Достаточно часто в нашей практике случается такая ситуация: клиент на каком-то шаге нашего знакомства говорит «я сейчас пришлю ТЗ на 1С», или посреди обсуждения будущего проекта берет таймаут со словами «я пошел писать ТЗ на 1С».
Часто, эта работа, не очень помогает исполнителю понять потребности клиента, оценить сроки и бюджет и забирает у клиента очень много времени, сил и энергии, отбивает всё желание делать проект

Почему так получается? Зачем нужно ТЗ, кто и как его должен писать, и что вообще должно содержать ТЗ на 1С – на все эти вопросы мы решили ответить.

Время прочтения: ~ 08 минут 25 секунд

Что такое ТЗ?

• ГОСТ 19.201
• ГОСТ 34.602

Давайте сразу решим, что про такие ТЗ (по ГОСТам) мы сейчас говорить не будем. Это для корпоративного заказчика, если вам в вашем проекте нужно именно такое «настоящее» ТЗ, вы наверняка знаете, что это, как оно пишется, и знаете где посмотреть ГОСТ и примеры ТЗ по ГОСТ.

В этой статье мы будем обсуждать упрощенное ТЗ, которое обычно пишут/запрашивают в 1С проектах, когда нужны доработки (иногда это называют так же ЧТЗ или «Частное техническое задание»). Почти никогда это не ТЗ по ГОСТу, но что же такое ТЗ содержит?

Как написать ТЗ?

Упрощенное («частное») ТЗ, которое нужно программисту 1С, должно содержать:

• Список объектов конфигурации, в которых необходимы изменения Изменения желательно описывать с точностью до реквизита и его типа, например, «Добавить в регистр накопления ХХ, ресурс ХХ, типа «число, два знака после запятой». (перечисления, регистры накопления и регистры сведений, справочники, документы, планы видов характеристик и так далее)
• Список новых объектов конфигурации, с детальным описанием типов данных, расположения реквизитов на форме, структуры интерфейса.
• Детальное описание алгоритмов системы – как система реагирует на нажатие пользователем кнопок, какие записи, в каких регистрах, делают документы, какие операции выполняются в регламентных заданиях.
• Юз-кейсы (пользовательские сценарии) – в них описан путь пользователя внутри системы, каким он должен быть для того чтобы пользователь решил свою задачу.

Для того, чтобы написать ТЗ – необходимо достаточно глубоко знать возможности платформы 1С, объекты, язык программирования. В принципе, нужно быть программистом, при том очень высокого уровня (архитектором).

Когда ТЗ на самом деле нужно

Обычно ТЗ нужно для большой разработки. Если модуль пишется с нуля, или создается подсистема, или сложная интеграция, без ТЗ не обойтись.

Если речь идет про внедрение типовой системы 1С, или даже с доработками, ТЗ скорее всего не нужно. Какой документ вам понадобится, и какова его структура?

ТЗ – пишут специалисты для специалистов

Мы уже обсудили, что ТЗ обычный человек (не айтишник, не программист), составить не сможет. Более того, с большой вероятностью он не сможет их и прочитать, и понять. В этом случае «согласованное ТЗ» имеет низкую ценность, заказчик «согласовал» ТЗ, потому что без этого нельзя двигаться дальше. Но он его не понял, не представил, как будет выглядеть и работать конечный результат. А значит вряд ли получит ожидаемое.

Если действительно нужна разработка на 1С, и необходимо описать свою задачу так, чтобы добиться единого понимания между Заказчиком и Исполнителем, рекомендуем писать ФТ.

Что такое ФТ?

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

Если вы сможете понять ФТ, согласованное с Исполнителем (и поправить его) высока вероятность что вы как Заказчик получите нужный вам результат.

ФТ может быть написано, например, так:

«Необходимо добавить на форму кнопку, при нажатии на которую пользователем будет происходить следующее:

1. Открывается форма для выбора интервала дат. При вводе дат пользователем система проверяет, что дата 1 меньше чем дата 2, и обе они меньше сегодняшней даты.
2. Еще на этой форме есть кнопка «Проверить отклонения». Пользователь нажимает на эту кнопку, если даты 1 и 2 заполнены
3. Система выбирает документы типа «Заказ покупателя», находящиеся в интервале между датой 1 и 2, в которых цена реализации не совпадает с текущей на дату документа ценой по прайсу.
4. Все эти документы система выводит в список, который …»

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

Кто должен писать ФТ и ТЗ?

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

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

Есть подрядчики, которые пишут ФТ сами, сняв задачу голосом. Конечно они возьмут чуть больше денег, чем те, кто работает «только по готовому ТЗ». Зато вы сэкономите немало своего времени и нервов сначала на описании задачи, а потом на ее приемке. Поищите и найдете тех, кто ФТ пишет сам, отталкиваясь от задачи, поставленной устно. Конечно, Корада работает так – мы умеем снимать задачу с обычных пользователей и описывать ее

Но мы такие не одни, есть и другие бизнес-ориентированные компании. Вам тогда останется только прочитать, осознать и согласовать ФТ. Поверьте, это гораздо проще чем писать его.

С чего начать проработку своего проекта

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

Описание функций по опроснику

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

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

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

Цели и задачи автоматизации

Цели проекта – это очень важно. Каждому клиенту мы говорим, что «внедрить 1С» это не цель. Согласитесь, если бы бизнес мог стабильно расти, развиваться, и ему не нужна была бы никакая система, никто не стал бы покупать ни желтые коробки, ни лицензии, ни дорогостоящие услуги консультантов и внедренцев.

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

Хорошими формулировками целей может быть:

1. Сейчас я получаю управленческую отчетность спустя месяц, после того как закрылся квартал. Хочу получать достоверную управленческую в моменте отчетность в любой день, за период с начала квартала по текущую дату.
2. Сейчас выполнение заказа на производство занимает 10 дней. Хочу за счет согласованных усилий специалистов, и организованных закупок, сократить срок выполнения заказа до 5 дней.
3. Сейчас мы пользуемся системой excel файлов на сервере, в которые заносят информацию сотрудники, при этом происходят ошибки, иногда файлы затираются, сотрудники путают версии, сбиваются ссылки. Хочу получать те же самые показатели, но из системы, полностью избавившись от всех excel файлов.

Итоги

Мы взялись ответить на вопрос «как написать ТЗ на 1С проект», и надеюсь смогли разобраться, что:

• ТЗ бывает разное. «Большое» ТЗ – это техническое задание по ГОСТу, и вам оно врядли нужно.
• Есть «ЧТЗ» (частное техзадание) – это конкретный вид документа, нужный в разработке на 1С.
• ТЗ (если это действительно ТЗ) должны писать сильные технические специалисты, заказчик, если он не глубоко погружен в технологии, вряд ли сможет его написать, и не должен этого делать.
• Есть альтернатива, ФТ. Функциональные требования заказчик может написать, и может понять, что в них написано.
• Удобнее найти подрядчика, который напишет ФТ сам (сначала допросит вас, а потом напишет на человеческом языке как все будет выглядеть и работать). И не будет вас «загружать» с ТЗ и тем более требовать от вас этот документ.
• Для того, чтобы сформулировать свои мысли, ожидания от информационной системы, требования к ней, можно подумать и записать ваши цели, и заполнить опросник/бриф. Например, взяв за основу наш.

Буду рад, если статья оказалась вам полезной. И если вы задумаетесь о внедрении 1С, вы не станете тратить время и моральные силы, на попытки создать ТехЗадание. Оставьте лучше энергию на проект, там она вам точно пригодится

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

Как писать функциональные требования

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

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

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

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

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

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

Функциональные требования: что это такое и зачем они нужны

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

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

Функциональные требования, как правило, состоят из:

• User story — показывает, чего вы ожидаете от команды разработки
• Use cases — показывают сценарии использования фичи
• Wireframes — средство визуализации своей идеи

User story

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

Как правило используется шаблон:

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

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

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

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

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

Цель пользователя в том, чтобы хранить изображения в нашей платформе и использовать их для создания email-кампаний.

Задачи пользователя:

• Загружать изображения
• Вставлять изображения в шаблон письма
• Удалять изображения

Примеры use case’ов:

• Email-маркетолог заходит в свой личный кабинет Retail Rocket
• Email-маркетолог открывает раздел «Галерея»
• Email-маркетолог загружает изображения через draghttps://habr.com/ru/company/retailrocket/blog/431572/» target=»_blank»]habr.com[/mask_link]

  Классификация требований. Часть 1. В общем о главном.

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

  Один из таких рудементов прошлого — это классификация требований по Вигерсу:
  
  

  Есть также и другие классификации. Частично сравнение можно найти у Юрия Булуя в презентации:
  http://www.uml2.ru/books/func-startdown/135/
  И даже недавнее предложение Дениса Бескова представить классификацию по новой:
  http://www.facebook.com/photo.php?fbid=10151692860420828type=1https://www.uml2.ru/community/blog/1273/» target=»_blank»]www.uml2.ru[/mask_link]