<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Вода водой.
Александр мое почтение. Но хотел бы уточнить как с использованием гибких методик ограничивать заказчика в стремлении впихнуть невпихуемое в 3 рубля и 1 день за нетленку? Ес
Добрый вечер, Александр. Имеешь в виду, как воспитать у заказчика разумные ожидания к срокам и стоимости решения его меняющихся хотелок?
Читая про очередную серебряную пулю в виде той или иной методики всегда хочется понять на каких типах проектов она применялась. Согласитесь большая разница между производством коробочного продукта без конкретного заказчика, заказной разработкой или внутренней разработкой для соседнего отдела. Так вот вопрос — RMS это для каких проектов? Ну и согласен с первым комментарием — хотелось бы больше конкретики.
Основная часть проектов осуществляется в рамках комплексного обслуживания 1С:Предприятия 7.7 и 8, включая программирование. Объем 80-2400 часов, сроком 3 недели — 1/2 года. Срок и стоимость в 2-4 раза выгоднее, чем аналогичный проект построенный по стандарту PMBOK PMI 4 Edition.
Обычно, берем одну или несколько типовых конфигураций (УТ, БП, ЗУП, КА, УПП, УСО, УНФ, Консолидация), выполняем доработки (если требуются), настраиваем, организуем РИБ и интеграцию с внешними системами (Oracle, Hypirion, SAP, системами ЭДО и специализированными, типа «Таможенный брокер»), консультируем по использованию, развиваем.
Иногда пишем заказные конфигурации с нуля или на основе 1С:БСП — недавно за 90 дней разработали на основе 1С:БСП и внедрили WMS.
По какой именно части методики хотите получить больше конкретики, конкретизируйте, пожалуйста 🙂
Каких источники порекомендуете по вышеуказанным методологиям?
предполагаем
Есть заказчик и есть исполнитель
Исполнитель хорошо знаком с предметной областью
На этапе техпроекта оговаривается сумма и требуемый функцмонал
Почему нельзя (или можно?) дальше работать по гибкой методике, программируя/разрабатывая нужный функционал?
И все, подписали договор кровью 🙂 , дальше вы вынуждены выполнить только то, что прописано в тех.проекте и уложиться в оговоренную сумму (жесткая методика). Сколько времени у вас займет составление тех.проекта для проекта 1/2 — 1 год? Наверное, от 1 до 3 месяцев? За время составления тех.проекта отсутствует какое-либо поступательное движение к решению (конфигурации без изменений, пользователи работают, как раньше). Во время разработки, тех.проект может устареть, соответственно, 1-3 месяца работы потеряны.
Я же говорю о гибкой методике работы, когда в начале проекта отсутствует определенность в том, что конкретно надо сделать (тех.проект) и во сколько это обойдется. Однако, если строго следовать моей технологии, то требуемая функциональность появляется в ожидаемые для заказчика сроки, за приемлемую для заказчику плату. Вместо тех.проекта, например, недельные результативные итерации, шаг за шагом приближающие к конечному решению. Так, например, нам удалось за 3 месяца разработать и внедрить заказную WMS с экономией половины бюджета в сравнении с проектом внедрения коробочной WMS, а если посчитать экономию на лицензиях, выигрыш еще значительнее!
Вышеуказанные — в статье или в комментарии к статье? 🙂
Если в комментарии, то первоисточник в PMBOK PMI 4 Edition (жесткие методики) и в PMBOK PMI 5 Edition (добавлены гибкие методики).
Если в статье, то могу сказать, что свою технологию начал строить раньше, чем появился PMBOK PMI 4 и, тем более, 5 редакция. Поэтому, наверное, в RMS больше взято из RUP, с учетом специфики проектов на платформе 1С:Предприятие. Могу рекомендовать пару книг:
1) Марри Кантор. Управление программными проектами. Практическое руководство по разработке программного обеспечения. Издательский дом «Вильямс». 2002 г.
2) Уокер Ройс. Управление проектами по созданию программного обеспечения. Унифицированный подход. Издательство «ЛОРИ», 2002 г.
О самой RMS имеет смысл, прочесть на моем сайте или задать более конкретные вопросы в личку или по электронной почте 🙂
(8)
Гибкие методологии подразумевают
вменяемостьгибкость заказчика. Если это требование соблюдается, то ничто не мешает в рамках договора, подписанного кровью подписывать допсоглашения и протоколы, которые позволят гибко реагировать на изменения требований.Сомневаюсь, так как требования меняются существенно быстрее, чем проводится согласование и подписание всяких документов в объемных проектах крупных заказчиков.
В моем опыте есть проект (по жесткой методике), когда тех.проект готовился 1 месяц + 1 месяц согласовывался и подписывался + 3 месяца разрабатывался, но к моменту сдачи изменился один принципиальный момент, что привело к невозможности принятия решения заказчиком (решение устарело относительно тех.проекта). За месяц после этого пришлось все переписать, но уже по гибкой методике, без всяких тех.проектов.
(11)
Мне кажется, что это крайность — приписывать долгие процедуры согласования жестким проектам. Любые решения согласовываются не более 1 дня, в сложных случаях не более 3х дней. Если дольше, то скорее всего есть глубинные проблемы, которые мы не предвидели и они не технического характера. Если у вас согласование длится месяц, то это значит, что ошибочно была выстроена коммуникация на проекте, имхо. При чем тут методы?
Как будто кто-то запрещает выстроить такую архитектуру проектной команды из исполнителя и заказчика, чтобы 99% согласований происходило чуть ли не мгновенно, порождая очередной протокол.
Я не сторонник жестких методов, но мне кажется приписывание именно этих свойств гибким методам не совсем оправдано. В конце концов люди строили деловые отношения и до всяких там методов, все эти методы лишь формализация до конкретных инструментов.
В чем вы меня хотите убедить, что в жесткой методике управления проектами можно обойтись без технического проекта?
Я, лишь, ответил Сергею, что если он начал проект по жесткой методике — составил технический проект и договорился о его стоимости, то его задача сводится к тому, чтобы выполнить этот тех.проект и уложиться в договорную стоимость.
А вы допускаете комбинирование жесткой и гибкой методики работ на одном проекте — фиксировали состав и стоимость работ, а начали потом работать в другом направлении за другие деньги?
Я отвечаю за свою методику — гибкую по сути. Которой, в отличие от жестких методов, свойственно: итеративная разработка, динамическое формирование требований, самоорганизующиеся рабочие группы, тесное взаимодействие. Вы эти свойства приписываете жестким методикам?
Да, именно так и строится работа по гибкой методике — «тесное взаимодействие», «динамическое формирование требований». У вас есть пример, когда это реализовано в жестком проекте?
(13)
Вы ложно полагаете, что я хочу вас в чем-то убедить. Но это просто общение. Мне не все понятно и не понятны некоторые аргументы, поэтому я пишу.
Да мы только так и работаем, составляем техпроект, подписываемся под фиксированные сроки и суммы, начинаем все делать и потом играемся в этих ограничениях, когда возникают изменения требований.
Тут важно, чтобы со стороны заказчика участники понимали, что позднее изменение требований (после реализации задуманного) влечет согласование изменение бюджетов и сроков. Раннее изменение (до реализации) влечет согласование изменение состава работ. Для того, чтобы снизить риски поздних изменений на этапе разработки происходит частая сдача работ.
Эти же риски справедливы и для гибких методик. Через полгода реализации по гибкой методологии бизнес меняется и все равно все придется переделывать, используя эти же гибкие методики.
Эти риски поздних изменений не предсказуемы. Бизнесу приходится реагировать на рыночне изменения так же внезапно, как внезпно эти изменения возникают. Например, никто не ждал, что рубль так обвалится. И если раньше использовали систему мотивации от маржи, где маржа считалась как цена продажи минус последняя цена закупа. Вот так всегда считали и привыкли. То после обвала рубля, решили считать цену продажи минус среднюю себестоимость. Иначе еще и должны останутся. А уже все сделано, протестировано и завтра запуск. Какие методологии помогут это избежать? )
Да, по факту получается некоторое совмещение жестких и гибких методов. Жесткое описание техпроекта позволяет нам формализовать стратегию развития информационной системы, т.к. техпроект строится не из текущих требований, а из требований для развития бизнеса заказчика, т.е. того, чего еще нет. Исходя из стратегии выбирается решение и в процессе решения возможны отклонения, которые требуют отдельного управления.
Мне кажется мы говорим об одном и том же, но разными словами. Просто, мне кажется, вы занимаете позицию не обсуждения, а противопоставления вашего мнения и любого другого.
Гибкие 🙂 Мы избегаем значительной части рисков. Например, вместо тех.проекта у нас готов работающий прототип за сопоставимый срок и стоимость, а у вас разработка только начинается после тех.проекта.
В тех.проекте отсутствовало понятие средней себестоимости? Что такого катастрофичного в случившемся — заменить один элемент формулы расчета на другой?
Совмещение по-моему отсутствует, вы используете жесткую методику. В жестких методиках тоже есть процессы, связанные с управлением изменениями, содержанием, сроками, стоимостью, рисками и пр. но очень далеко до динамического формирования требований. Присмотритесь, например, к 5 слайду — как вы сможете предусмотреть в тех.проекте и обеспечить решение ресурсами при такой изменчивости потребностей, сформируете команду с производительностью 700 часов в месяц? Чем команда будет занята, когда требований существенно меньше?
Стратегия развития информационной системы и тех.проект — это два очень разных по масштабу и уровню детализации понятия. Стратегия — это то, что объединяет гибкие и жесткие методики. Наличие у вас тех.проекта является отличием от нашей методики, у нас требования формируются динамически, хотя и в рамках стратегии. Но на то оно у нас и называется «Управление требованиями».
По какому аргументу вам предоставить пояснения?
Набирает популярность наигибчайшая методология DevOps .
Как раз для одинэсников.
Цикл такой: фигак, фигак( 1 день )=>продакшн(на утро)=>визги, звонки(к обеду)=>пересогласовывание требований + перепродакшн (часто динамический)
(16) Wooster, если у вас используется автоматизированное тестирование, код покрыт тестами на 100% , у вас настроенные регламенты и скрипты для быстрого обновления, отката в случаи ошибки и все это делает компьютер, а не человек тыкает мышкой «Обновить конфигурацию из хранилища» и т.д. , то почему бы и нет?
(15)
Вы заставили меня посмотреть на нашу деятельность под новым углом. Поразмыслив, решил, что сначала копну чуть поглубже вашу тему и если возникнут вопросы, тогда уже и напишу.
Александр,
1) Могу ошибаться, но на слайде в левой и правой колонках написано одно и то же разными словами, притом, в правой даже на одну фичу больше 🙂 Мы то знаем, что слева- про одну небольшую «итерацию» (или маленький этап из пары итераций ), а справа- про весь проект (несколько этапов), но вдруг кому-то будет не очевидно.
2) Вопрос. Как часто не удается продать Agile новому клиенту, незнакомому с особенностями производства ПО, и требующему назвать полную стоимость и сроки ? Как поступаете, продаете «водопад», чтобы начать работу, втереться в доверие и переиграть по ходу ? (Потенциальный клиент-то может быть желанный. Но он, например, из строительства и знает,что на калькуляторе можно рассчитать стоимость и сроки застройки острова Русский, и они будут точны. А тут какая-то программка.)
3) Вопрос. От сотрудника требуете КПО, это понятно и единственно правильно, на мой взгляд. А вот от клиента или сотрудника клиента ? (Пример. Вот мне пришел запрос: «10,09-ВВЕДЕНА КАК ВВОД НАЧАЛЬНЫХ ОСТАТКОВ ТРЕБОВАНИЕ ИХ НЕ ВИДИТ!!! НЕ МОГУ ЗАКРЫТЬ ПЕРИОД ВАМ ЗВОНИЛА-ТРУБКА НА ЯЩИКЕ.») Как-то влияете на клиентов, переучиваете, снабжаете шаблонами, подсаживаете на хелпдески, увольняете, расшифровываете, принимаете как данность и смиряетесь ? Ответа тут не прошу, понимаю, что тут можно много сказать, и это отдельная тема. Можете учесть как потенциальную тему докладов на конференциях 🙂
(19) Wooster,
Да, ошибаетесь. В правой колонке требования, сроки и бюджет определены, фиксированы. В левой колонке работа ведется в условиях динамического формирования требований, сроков и стоимости — описан, по сути, критерий качества всей работы с клиентом в множестве проектов, на длительном периоде времени, с еженедельным (для клиента) контролем качества.
Эджайлом не торгую 🙂 Клиенту без разницы, по-моему, как и что у меня организовано внутри. Случаи отказов от заключения договора есть, но статистика отсутствует. Для меня более важный критерий — отказ от продолжения сотрудничества по договору из-за отсутствия у клиента удовлетворенности обслуживанием. Каждый случай такого отказа был проанализирован, установлены причины, приняты меры к предотвращению подобных случаев в будущем.
Для таких клиентов у меня есть несколько ответов:
1) «Сформулируйте ожидания к функциональности, срокам и стоимости». В этом случае можем отказаться от сотрудничества, если сформулированные требования к функциональности, срокам и стоимости существенно отличаются не в нашу пользу от аналогичных решений, история которых сохранена в RMS. Обычно, клиент затрудняется с формулировкой, так как находится в точке минимальной определенности и имеет выбор — воспользоваться любым методом оценки проекта самостоятельно, обратиться повторно, когда появится определенность в ограничениях или доверить нам, организовать сотрудничество в строгом соответствии с технологией и гарантировать ему получение требуемой функциональности, в ожидаемые сроки, за приемлемую плату 🙂
2) «Мы можем оценить проект, например, по методу аналогий (по прошлым решениям, сохраненным в RMS), удвоить или утроить предполагаемую стоимость, страхуясь от рисков, связанных с почти полным отсутствием определенности на начальном этапе проекта». У клиента выбор — настоять на фиксированной стоимости и получить решение в 2-3 раза дороже, чем доверить организацию сотрудничества строго по нашей технологии (без гадания) и получить требуемую функциональность, в ожидаемые сроки, за приемлемую плату (с еженедельным контролем) 🙂
3) «Откажемся от гадания стоимости, организуем сотрудничество по нашей технологии, если результат сотрудничества в течение 2 недель не устроит, расторгнем договор, вернув деньги». В таких случаях, 2 недели вполне достаточно для клиента, чтобы «почувствовать разницу» и остаться с нами на долгие годы.
Ответ есть в статье 🙂
Вопросы к автору 1)насколько присутствие в не-домашнем регионе возможно
2) каким образом организуете взаимодействие в комплексных проектах с партнерами(например с системными интеграторами)и есть ли опыт?
3)И главный наверно вопрос, практический инструментарий ведения проектов по данной методологии?
(21) AlexSunS, попробую ответить, как понял:
Присутствие возможно во всех регионах, где клиенты способны читать и писать на русском языке. Самые удаленные от нас клиенты на сегодня живут и работают во Владивостоке.
Подключаем партнеров к RMS параллельно с представителями заказчика. Реже, через посредников из числа специалистов заказчика.
Основу инструментария составляет «Система управления требованиями — RMS (Requirements Management System)». Программно, это web-интерфейс, разработанный по заказу на php, тесно связанный с CVS через собственную разработку для сборки/разборки конфигураций на платформе 8 и через GComp на платформе 7.7. Организационно — собственная технология управления распределенными программными проектами с рабочим названием «Управляемое внедрение», построенная на основе RUP. Философски — технология win-win (Джон Форбс Нэш «Теория игр с ненулевой суммой»).
К сожалению умение читать и понимать что написано, так же как и умение четко и ясно писать — ни одна система автоматизации не привьет.
А это — основная мне кажется проблема. Ну как избежать ситуаций неправильного понимания если например тот кто пишет некое задание в одном и том же письме себе противоречит, а также противоречит в других письмах, на которые ссылается в этом письме. Создается каша из «того что обсуждалось». И как в борьбе с этим может помочь система ?
(23) alex_4x,
Ответ содержится в вопросе — все дело в системе! 🙂 Система — это 1) люди 2) программные средства и методики 3) философия.
Устранение противоречивости большинства требований происходит на нескольких этапах:
1) процесс «анализ и достижение понимания требований» результатом которого является согласованный «воспроизводимый пользовательский пример» (ВПП).
2) процесс «модель без доработок» результатом которого является работающий прототип с перечнем предполагаемых доработок.
3) в последующих процессах «конкурс концепций», «разработка», «тестирование», «внедрение».
Так как у заказчика несколько контактных лиц работает в RMS, то значительное количество противоречий устраняется самим заказчиком (один противоречит, другой возражает, наш руководитель помогает — этап 1).
Встречаются, конечно, более сложные случаи противоречивости требований, выявляемые через год и более после внедрения, но, во-первых, эти противоречия скрыты, предугадать в начале достаточно сложно. Во-вторых, как только противоречие возникает, его разбор и устранение возвращается на этап 1 «анализ и достижение понимания требований».
(22) Собственно как раз Владивосток домашний регион, как с вами связаться ?
(25) AlexSunS,
Напишите в «личку» или на нашем сайте есть все реквизиты 🙂
Спасибо! Очень интересная статья, многие моменты на себе прочувствовал.
1. Насколько я понял, ключевая фишка — быстрая реализация и демонстрация прототипа.
Какие ограничения вы накладываете на прототип? Насколько он кликабельный/рабочий?
Кто его делает — программисты или аналитики (или это один человек)?
2. Для чего вы рекомендуете использовать почту, а для чего только непосредственный контакт?
— Первичный анализ и реализация прототипа.
— Формализация/закрепление состава требований с заказчиком.
— Организация внутреннего взаимодействия команды.
— Еще…
3. Вы не могли-бы подробнее описать чем плохи и гибкие и жесткие методики?
Ну, вот, самые такие суровые, показательные примеры.
Например, если вы не закрепляете состав работ на бумаге, то как потом выбиваете деньги с заказчиков?
Требуют ли заказчики доработки и поддержки до фактической оплаты?
Аппетиты, как известно, растут во время еды…
Если ответы — коммерческая тайна, то можно не отвечать.
(27) Kiber_,
Нет, ключевая фишка — сотрудничество между заказчиком и исполнителем 🙂 Прототип — это почти решение, возможно, без отдельных деталей, но принципиально уже рабочее. То есть, над прототипом уже поработали специалисты (РП, разработчики, тестеры) на нескольких этапах от анализа до внедрения.
Рекомендуем использовать в порядке предпочтения: 1) Web-интерфейс RMS 2) email 3) телефон 4) личный контакт. Если не удается достичь понимания письменно (пункт 1,2), пользуемся телефоном. Если по телефону трудно, личный контакт.
Гибкие методики — вынужденная мера при работе с программными проектами, особенно в условиях, когда состав работ определяется по мере внедрения продукта. Минус гибкой методики, наверное, в отсутствии точного понимания «сколько это будет стоить?» и «когда это закончится?». Чтобы снизить влияние этих минусов в разных методиках применяются разные методы, например, в SCRUM добавлен процесс, когда фиксируется объем работы в пределах одной итерации — элемент из жесткой методики.
Минус жесткой методики — фиксируется один состав работ, а реально работать надо по другому составу. Оценка бюджета при жесткой методике тоже работает чаще против подрядчика, так как оценка производится на этапе максимальной неопределенности проекта. Только 9% крупных программных проектов укладывается в запланированный срок, согласованный бюджет, с удовлетворением около 80% задуманной функциональности.
Стараемся договориться, убедить. При принципиальном отказе заказчика от оплаты, расстаемся, с отказом от поддержки и гарантий.
Требуют, случается. Ошибки исправляем, от выполнения доработок при отсутствии оплаты отказываемся.
Вот теперь — точно все понятно. Спасибо!