Автор Тема: Регламенты по разработке собственных обектов и модификации стандартных  (Прочитано 58667 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Регламент... Каждый хоть раз читал и критиковал, будучи твердо уверенным, что смог бы сделать лучше. Тем, кому интересно, предлагается совместными усилиями сделать достаточно универсальный набор документации для разработчика. Пилотные форму выложу чуть позже.

Dmitriy: добавил... Все конструктивные предложения (не граничащие с полной обструкцией) и дополнения приветствуются.
« Последнее редактирование: Сентябрь 24, 2009, 06:23:59 pm от Dmitriy »

Оффлайн Skif

  • Jr. Member
  • **
  • Сообщений: 726
  • Репутация: +10/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
Регламент... Каждый хоть раз читал и критиковал, будучи твердо уверенным, что смог бы сделать лучше. Тем кому интересно предлагается совместными усилиями сделать достаточно универсальный набор документации для разработчика. Пилотные форму выложу чуть позже.
амосов пытался в своё время...кстати уже обратился к нему со своей траблой - молчит пока - в отъезде может
описание его "концепции" в инете есть - поищи "стандарты амосова"

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
амосов пытался в своё время...кстати уже обратился к нему со своей траблой - молчит пока - в отъезде может
описание его "концепции" в инете есть - поищи "стандарты амосова"
О! спасибо. Плодовитый мужик Виктор Амосов ака 111.

Оффлайн Skif

  • Jr. Member
  • **
  • Сообщений: 726
  • Репутация: +10/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
О! спасибо. Плодовитый мужик Виктор Амосов ака 111.
он это ещё в архангельске ваял - ломоносов млин ;)

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
You are not allowed to view links. Register or Login
он это ещё в архангельске ваял - ломоносов млин ;)
Да было дело.. помню такое... а так в общем, ждем бета версию от Дмитрия, вот за нее и возьмемся...

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul  link=topic=805.msg5010#msg5010 date=1253712422
Да было дело.. помню такое... а так в общем, ждем бета версию от Дмитрия, вот за нее и возьмемся...
Можно смотреть, прикрепил к первому сообщению.
В номере ТЗ NNNN-VV-GG:
NNNN - порядковый номер ТЗ по реестру (сквозная нумерация по факту поступления)
VV - версия
GG - модуль.
Соответственно в имени программы первые 10 символов в виде ZNNNN_VV_GG или ZGG_NNNN_VV (не определился, но второй вариант больше нравится).

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
You are not allowed to view links. Register or Login
Можно смотреть, прикрепил к первому сообщению.
Я конечно сильно извиняюсь но вот этот вот docx, я прочитать не смогу, так как это тока последний ворд умеет коего у меня нет. Если можно сохранить или в обычном doc или rtf ну или на худой конец pdf  ::)

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul  link=topic=805.msg5018#msg5018 date=1253716021
... ну или на худой конец pdf  ::)
Ну pdf для бета-версии - это действительно на худой конец. ;D

Оффлайн Skif

  • Jr. Member
  • **
  • Сообщений: 726
  • Репутация: +10/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
Ну pdf для бета-версии - это действительно на худой конец. ;D
я бы вообще предпочёл otf

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
я бы вообще предпочёл otf
Ну давайте попробуем odt.

Оффлайн Удав

  • Newbie
  • *
  • Сообщений: 44
  • Репутация: +7/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
По поводу соглашений по именам - общий смысл заключается в том, чтобы в ролях разработчика одинаковые объекты описывались по маске.
А сколько именно символов отводится на маску, нужна ли например отдельная маска на транзакции  - это дело традиций проекта и прошлого опыта разработчика соглашения по именам :)

Предложения по документации на разработку:
1.Номера запросов в документации можно не указывать, т.к. их можно посмотреть в системе разработки через SE01 (меню "Запрос-Поиск запросов", а менять под каждый чих документацию разработчик (или ответственный за перенос запросов) как правило считает бессмысленным трудом.
2.В документации лучше указывать объекты разработки и программные блоки (ключевые ФМ и процедуры) с кратким описанием. Понятно, что все это можно увидеть в коде, но когда разработка включает в себя несколько программ и групп функций, то в SE80 их по отдельности смотреть не очень приятно.
3.Изменения в постановке задачи лучше делать в самом тексте, а не выносить вниз постановки. Со временем придется читать все изменения, а постоянно смотреть сначала исходный алгоритм, а потом его изменения - удовольствие не из приятных. Мы остановились на таком варианте: в кратком описании задачи аннтотация к изменениям вставляется в конец.
А в описании алгоритма исправления делаются в режиме рецензирования (правда это подходит только к Microsoft Word).
Перед написанием новой версии постановки все предыдущие изменения применяются. Таким образом всегда видно, какие изменения были внесены в этой версии.

Оффлайн Skif

  • Jr. Member
  • **
  • Сообщений: 726
  • Репутация: +10/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
По поводу соглашений по именам - общий смысл заключается в том, чтобы в ролях разработчика одинаковые объекты описывались по маске.
А сколько именно символов отводится на маску, нужна ли например отдельная маска на транзакции  - это дело традиций проекта и прошлого опыта разработчика соглашения по именам :)

Предложения по документации на разработку:
1.Номера запросов в документации можно не указывать, т.к. их можно посмотреть в системе разработки через SE01 (меню "Запрос-Поиск запросов", а менять под каждый чих документацию разработчик (или ответственный за перенос запросов) как правило считает бессмысленным трудом.
2.В документации лучше указывать объекты разработки и программные блоки (ключевые ФМ и процедуры) с кратким описанием. Понятно, что все это можно увидеть в коде, но когда разработка включает в себя несколько программ и групп функций, то в SE80 их по отдельности смотреть не очень приятно.
3.Изменения в постановке задачи лучше делать в самом тексте, а не выносить вниз постановки. Со временем придется читать все изменения, а постоянно смотреть сначала исходный алгоритм, а потом его изменения - удовольствие не из приятных. Мы остановились на таком варианте: в кратком описании задачи аннтотация к изменениям вставляется в конец.
А в описании алгоритма исправления делаются в режиме рецензирования (правда это подходит только к Microsoft Word).
Перед написанием новой версии постановки все предыдущие изменения применяются. Таким образом всегда видно, какие изменения были внесены в этой версии.
процесс пошёл однако;)

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
процесс пошёл однако;)
Да, что не может не радовать. Просто дело в том, что любой более-менее вменяемый вариант от меня будет принят и одобрен (бета версия уже на рассмотрении), а хотелось бы как лучше, чтобы не юзать то, что получилось "как всегда", поэтому и обратился к специалистам... ;)

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Стандарт наименований собственных объектов разработок
Цитировать
Название проекта
Номер проекта/сроки
Вид проекта (внедрение, апгрейд, внутренний, прочее)
В этом блоке я бы разнес номер проекта и сроки, т.е. сделал бы сроки проекта отдельной ячейкой типа с DD/MM/YYYY по DD/MM/YYYY.

Цитировать
Наименование заказчика
Руководитель/заместитель руководителя проекта от заказчика
Руководитель/заместитель руководителя проекта от исполнителя
Написал бы наименование заказчика/Инициатор проекта, так как иногда инициатор и заказчик могут быть разными людьми.

Цитировать
1. Управление документом.
Я сюда добавил бы статус документа типа: Черновик/Базовый документ/Согласование/Финальная версия и т.д. А дальше типа таблица утверждения документа, не знаю насколько важна версия, обычно утверждают последнюю версию и она общая для всех или ты предполагаешь, что разные люди утвердят разные версии? Так это не правильно, мало ли что изменится после того как кто-то согласовал первую версию. Я бы номер версии вынес в заголовок это таблицы, т.е. все согласуют одну и ту же версию документа.

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

Цитировать
Имена объектов репозитория:
XYYZZZZZZ_NN
Первая Z или Y, вопросов нет, далее тип объекта, тоже как бы не вопрос, а вот поля ZZZZZZ и NN вызывают следующие мысли. Я не понимаю что значит код разработки по реестру, т.е. это что? Т.е. предлагается вести сквозную нумерацию всех объектов где-то в таблице и брать номер из этой таблицы? Следовательно я делаю например 10 доменов, называться они у меня будут c ZDO000001_00 по ZDO000010_00, но тут видим сразу же одну проблему, во-первых нули и буква "О", однако сливаются, второе это значит что должен быть человек который ведет таблицу реестра и выдает номера, ну такой себе аналог транзакции SNUM, опять же, а если я запросил домены не все сразу? Это приводит к тому, что мои домены будут разбросаны... в перемежку с чужими? В общем как по мне нужно добавить/расписать как предполагается давать имена вот этому блоку ZZZZZZ! Далее версия которая равна номеру запроса, мне не ясна, так как SAP ведет версии сам, ну если вы используете версии. так что не вижу смысла в этом номере. в общем я бы сделал маску типа
XYY_ZZZZZZ, где расписал бы правила ведения блока ZZZZZZ, я в этом ZZZ бы или кодировал ключ/код разработчика + какое-то смысловое наименование а не номер, например для домена номеров товарных вагонов, я бы написал что-то типа ZDO_UUKNUMWAGON.

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

Цитировать
Именование функциональных модулей BAPI
Ну вообще-то BAPI пишет только SAP, а се остальные пишут разные ФМ, так что я бы убрал вообще нафиг этот префикс BAPI, так как тогда не ясно какая разница между просто моим ФМ и моим же ФМ но я решил что это будет BAPI. Если считать что BAPI это ФМ который пишет таблицы базы данных тогда как минимум по твоему документу у него должно быть имя ZFMBAPI*, но тогда ФМ на чтения давай называть ZFMSELC*, ФМ в которых разные расчеты пусть будет ZFMCALC и т.д. а иначе получается на ФМ у нас действуют два стандарта.

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

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul
Я не понимаю что значит код разработки по реестру, т.е. это что? Т.е. предлагается вести сквозную нумерацию всех объектов где-то в таблице и брать номер из этой таблицы?
Да. Кто-то пишет свою программу и ведет этот реестр в SAP, периодически выгружая ее в Excel перед совещаниями. Лично я в свое время вел ее сразу же в Excel с минимумом полей, поскольку сам распределял разработки и был в курсе текущей ситуации. Нумерация в реестре сквозная, по мере поступления ТЗ. Т.е. подразумевается, что РГ разработки один и он находится на проекте с начала активной фазы и до первого успешного закрытия с последующей передачей дел на поддержку следующему счастливчику, но уже от заказчика. Статусы ТЗ:
1) постановка (стандартная разработка, 100% присутствуящая на проекте, например "загрузка контрагентов" и пр.), она внесена в реестр и пронумерована
2) утверждено
3) разработка
4) тестирование (тест, продуктив, пока не будет отмашки от отв. за тестирование)
5) завершено
Если ч/з некоторое время после завершения приходится дорабатывать, то повторение пп.3-5, если по реестру отдельно не проходит как новая версия ТЗ

P.S. Никаких накладок с нумерацией не было. После предварительной экспертизы РГ присваивает номер, дальше она только под ним фигурирует, пусть даже более поздние утверждены раньше и сделаны.  
« Последнее редактирование: Сентябрь 24, 2009, 03:08:09 pm от Dmitriy »

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
You are not allowed to view links. Register or Login
P.S. Никаких накладок с нумерацией не было. После предварительной экспертизы РГ присваивает номер, дальше она только под ним фигурирует, пусть даже более поздние утверждены раньше и сделаны.   
Понимаешь ли вот этот номер абсолютно не читаем при просмотре программ, не я помню одну разработку где поля в базе назывались N1, N2, N3 .... N102 ну было прикольно, ага тока надо было всегда схему держать под рукой чтобы знать какой N, что означает, ну и в запросах тоже циферкой ошибся, а чего базовые типы совпадают, зато на выходе можно потом долго искать. В общем я отношусь к тем людям которые считают что переменные должны хотя бы немного намекать на свою суть, это раз, а два... циферки можно и промахнуться....

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul  link=topic=805.msg5039#msg5039 date=1253794209
Понимаешь ли вот этот номер абсолютно не читаем при просмотре программ, не я помню одну разработку где поля в базе назывались N1, N2, N3 .... N102 ну было прикольно, ага тока надо было всегда схему держать под рукой чтобы знать какой N, что означает, ну и в запросах тоже циферкой ошибся, а чего базовые типы совпадают, зато на выходе можно потом долго искать. В общем я отношусь к тем людям которые считают что переменные должны хотя бы немного намекать на свою суть, это раз, а два... циферки можно и промахнуться....
Здесь согласен полностью, всегда держал под рукой, хотя не всегда нужно было в нее смотреть. Подобное обозначение малоинформативно, если не видишь заголовок/описание программы из 70-ти символов (макс). Плюс еще была такая неувязка: в общем реестре проекта по которому ориентировались уже РП с обоих сторон и по которой сёрфили на еженедельных совещаниях все было свалено в одну кучу и часто названия пунктиков у "них" не совпадали с описанием предложенном в ТЗ, либо вообще, соотношение пунктов составляло n:n. Но это уже вопрос ведения документации проекта в целом.

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
Техническое задание на разработку

Цитировать
1.1 Описание: Общее описание разработки, место выводимого документа (отчёта) в бизнес-процессе пользователя.
Я бы этот пункт разделил на два:
  • Цели разработки - т.е. для чего выполняется эта разработка
  • Область применения - для кого и как будет использоваться, ну там разовая разработка, периодически, раз в месяц и т.д. например в разовой разработке например лишним будет тратить время на выведение лога работы в ALV ли там красоту наводить, достаточно например ошибки обработки вывалить и т.д.
  • Требования к качеству/производительности - а то если это критичная вещь, например данные должны быть обработаны в течении и 30 минут, то тут как бы уже понятно что стоит потратиться на оптимизацию кода или писать просто без выкрутасов если скорость не критична. От этого имеет зависимость по времени разработки.

Цитировать
1.7.Данные для тестирования
Тут все сложнее, если тесты простые то как бы ясно, а если для тестирования нужно провести кучу документов? Опять же заказ на поставку может уже быть с таким номером использован и над делать новый?1 Так что будем менять документ при каждом прогоне тестов?!

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul
1.7.Данные для тестирования
Тут все сложнее, если тесты простые то как бы ясно, а если для тестирования нужно провести кучу документов? Опять же заказ на поставку может уже быть с таким номером использован и над делать новый?1 Так что будем менять документ при каждом прогоне тестов?!
В том-то и дело! Для простых отчетов, например, можно ограничится созданием варианта TEST, или внести в протокол тестирования номера документов и т.д. А если мы проводим с-ф ММ на основании заказа? Хотя можно выкрутиться и создать заказ на миллион, а проводить по 100... гривен. ;D Какие будут предложения? ::) И возможно ли перечислить типовые случаи помимо приведенного?
« Последнее редактирование: Сентябрь 24, 2009, 03:39:55 pm от Dmitriy »

Оффлайн Удав

  • Newbie
  • *
  • Сообщений: 44
  • Репутация: +7/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul  link=topic=805.msg5041#msg5041 date=1253795376
Техническое задание на разработку
  • Требования к качеству/производительности - а то если это критичная вещь, например данные должны быть обработаны в течении и 30 минут, то тут как бы уже понятно что стоит потратиться на оптимизацию кода или писать просто без выкрутасов если скорость не критична. От этого имеет зависимость по времени разработки.
Категорически не согласен. Производительность всегда должна быть хорошей. Разве постановщик, к примеру, должен дать задание написать расширение для стандартной транзакции или свою транзакцию ввода, которое будет тормозить?  ???

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
You are not allowed to view links. Register or Login
Категорически не согласен. Производительность всегда должна быть хорошей. Разве постановщик, к примеру, должен дать задание написать расширение для стандартной транзакции или свою транзакцию ввода, которое будет тормозить?  ???
Т.е. данный пункт лишний, заранее подразумеваем оптимальную производительность? Если так, то соглашусь. А уж как кто пишет - это вообще отдельная песня. 

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
You are not allowed to view links. Register or Login
Т.е. данный пункт лишний, заранее подразумеваем оптимальную производительность? Если так, то соглашусь. А уж как кто пишет - это вообще отдельная песня. 
Да нет... не совсем кто как пишет.. например если не критично, то я выберу данные из таблицы MSEG и если скорость устраивает то не буду заморачиваться на поиски всяких вторичные индексов типа BSIM и т.д. соответственно разработка будет быстрее и проще. Но если скорость не устраивает тогда я потрачу время на поиски этих вторичных индексов и таблиц, или мы сразу предполагаем, что точно знаем самый быстрый способ выборки требуемых данных? А если нет? Или время на поиски не учитывается при разработке, а оно ведь может быть существенным? В общем про категорически, что все должно быть самым быстрым не согласен... одно дело если ты это уже делал, то не вопрос, ты сделаешь так как быстро, а если не делал, то ты уверен, что сейчас написал все как надо?! В общем суть в том что в ТЗ на разработку надо указывать желаемое время отклика системы, если это критический показатель, если нет, то просто ничего не указываем... но я сталкивался с разработками, где сама программа была пару страниц, но вот чтобы ее сделать потребовалось пару месяцев, так как была критична каждая секунда ее работы.

Оффлайн Удав

  • Newbie
  • *
  • Сообщений: 44
  • Репутация: +7/-0
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Так в системе разработки мы никогда про реальную скорость работы не узнаем - объем данных не тот.
Поэтому в основном проблемы с быстродействием возникают в системе контроля качества или копии продуктивной системы.
То, что в разработке будет работать 5 секунд, в продуктиве может не отработать и за 20.
Если нужен контроль по времени выполнения разработки, то тюнинг быстродействия уйдет в этап тестирования.

Оффлайн Dmitriy

  • SAP ECC 6.0
  • Кухня
  • Newbie
  • *
  • Сообщений: 380
  • Репутация: +0/-0
  • Пол: Мужской
  • Embracive Fire
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Цитата: Uukrul
В общем суть в том что в ТЗ на разработку надо указывать желаемое время отклика системы, если это критический показатель, если нет, то просто ничего не указываем... но я сталкивался с разработками, где сама программа была пару страниц, но вот чтобы ее сделать потребовалось пару месяцев, так как была критична каждая секунда ее работы.
Есть отдельные ТЗ на оптимизацию, ну что же, если мы хотим универсальную форму ТЗ... Просто твой случай исключение из правил, хотя именно исключения и важны для качества нашего документа. Обычный "среднестатистический" консультант не сможет сформулировать требования, о которых ты говоришь, за исключением общего "необходимо, чтобы время выполнения программы не превышало такое-то значение". Но пунктик есть, значит кому-то обязательно захочется его заполнить чем-то с потолка. Нужно подумать. Обычно подобные требования возникают после некоего времени эксплуатации, а не сразу. Если приведешь пример, что там за задача была такая критичная, что прямо сразу при постановке, то буду только благодарен.

Dmitriy: пока писал, свой ответ запостил Удав. Нечто похожее я и имел ввиду.
« Последнее редактирование: Сентябрь 24, 2009, 04:35:56 pm от Dmitriy »

Оффлайн Uukrul

  • SAP ECC 6.0 Ehp(*)
  • Administrator
  • Epic Member
  • *****
  • Сообщений: 3 809
  • Репутация: +47/-0
  • Пол: Мужской
  • YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
    • Sapforum.BIZ
You are not allowed to view links. Register or Login
Но пунктик есть, значит кому-то обязательно захочется его заполнить чем-то с потолка. Нужно подумать. Обычно подобные требования возникают после некоего времени эксплуатации, а не сразу. Если приведешь пример, что там за задача была такая критичная, что прямо сразу при постановке, то буду только благодарен.
Ну скажем так пункт должен быть. Второе, чтобы время с потолка не писали, я бы там добавил что указав время, например 30 минут, нужно написать обоснование почему это максимально критичное время задачи. В том случае о котором я говорил выше время обусловлено было техническим циклом создания документов, т.е. скорость загрузки должна была быть, ну скажем 10 документов с секунду иначе, зная количество документов для обработки, получалось что система не успевала бы все обработать за сутки. Поэтому в этом случае я бы вписал типа скорость обработки не ниже 10 документов в секунду, данные требования исходят из объема всех загружаемых документов, объем которых ххххх штук.

Sapforum.Biz