Спасибо за хорошие вопросы.
1. Это, конечно, так. Термин «Потребности» нужно понимать действительно в широком смысле. Однако на практике, функциональные требования настолько доминируют над сознанием и отношениями, что прочие «смыслы» зачастую остаются на бумаге. Более того, не функциональные требования часто проверяются только в первой версии, а для последующих уже нет. Вот, например, классическая заглушка для ФТР одного из наших проектов 8. Обеспечение доступности
Функционально-технические решения по обеспечению доступности не изменяются и соответствуют описанию в соответствующем разделе ФТР предыдущей версии N.N
2. Нет, не противопоставление. Скорее я хотел донести идею, что использование автоматических средств анализа исходного кода — это своеобразный недорогой «code review». Разумеется, просмотр кода опытными разработчиками или архитекторами может помочь выявить серьезные ошибки проектирования, например. Однако, использовать такой ресурс для более простых задач анализа текста программы, которые гораздо эффективнее и быстрее решает соответствующий инструмент — это расточительство времени и сил. Опять же я привёл примеры, когда альтернативы анализаторам кода просто нет.
Что касается использование анализатора кода в качестве средства обучения хорошим правилам программирования, то здесь я бы поспорил. Когда анализатор выдаст исчерпывающую справку о найденной уязвимости с подробным описанием возможных последствий, предоставит примеры того, как код исправить, укажет на строки кода, где эта уязвимость обнаружена — то это уже вполне можно считать элементом обучения.
Например, для C# из Kiuwan
Overload Equals method on value types Description
For the value type «structure', default implementation of the method that determines the equality of two objects (Equals) habitually it will have a performance lower than a personalized implementation and because of this it recommends to personalize this method and Violation will appear when it is not like that. Code
OPT.CSHARP.Csharp.OverloadingEqualsValueTypes Reference msdn.microsoft.com/en-us/library/7h9bszxx(VS.80).aspx Violation code
public struct A { //VIOLATION
int x;
}
Fixed code
public struct A {
int x;
public override bool Equals(object o) //OK
{
A obj = (A)o;
return (this.x == obj.x);
}
}
3. Базовым результатом работы любого анализатора кода будет список найденных уязвимостей, ошибок, замечаний. Всё самое интересно начинается потом. Как работать с этим списком? Классификация, сортировка, группировка, приоритизация. Над этим слоем можно построить более общие отчеты по обнаруженным проблемам.
Выше — общая статистика по приложению
Выше — статистика по портфелю приложений, командам разработки или внешним исполнителям и многое другое. Пример общего отчета анализа С# приложения.
И это только срез отчетов после одной проверки. А если процедуру производить регулярно, то появится возможность посмотреть на информацию в динамике — кто улучшает качественные характеристики, кто ухудшает, по каким показателям и т.д.
Еще на один момент я обращал внимание в статье — насколько важно обнаруженные уязвимости преобразовать в задачи. Здесь два аспекта — оценка сложность исправления и доставка задачи исполнителю. И то и другое, например, есть в Kiuwan — система помогает примерно оценить в часах, днях сколько нужно времен на исправление. Есть выгрузка в Excel. Есть интеграция с Jira / SBM. Наверное можно и с другими трекерами установить „рабочие отношения“.
Вот теперь это уже не только инструмент самообразования программиста, а полноценный инструмент контроля качества серьезной организации, как мне представляется.
4. Как известно, есть две парадигмы в отношении управления людьми. Или нужно исходить из того, что все сотрудники лентяи, бездари, халтурщики и т.д. или наоборот, что они все молодцы, болеют за дело, как за свое, пожертвуют своим временем и здоровьем ради проекта и т.д. Я обычно исхожу из „второй“, а получается как в „первой“. :)
5. Я даже скажу больше. Важно не только отбрасывать ложные срабатывания, но и „отключать“ целые типы уязвимостей, которые для ваших обстоятельств использования приложения, например, значения не имеют.
В Kiuwan пользователь может отключить отдельные найденные ошибки — »Mute" — и они больше не попадут в отчет даже при повторном анализе. Либо настроить свою модель качества приложений, повысив приоритет одних характеристик и снизив для других, что отражается и для расчета метрик и для поиска уязвимостей. Либо загрузить свои правила обнаружения дефектов.
С этой точки зрения, любые платформы-конструкторы бизнес-приложений, игр, web-сайтов и платные, и бесплатные «привязывают» к себе пользователя. Совершенно невозможно себе представить мягкий быстрый переход, например, с WordPress на Goomla или с Jira на SBM. Но так ли это плохо?! Платформы-конструкторы действительно сильно упрощают многие задачи и операции разработки новых приложений, резко повышают эффективность разработки. Если смотреть на этот вопрос еще шире, то даже чистое программирование на C# на самом деле резко сужает для вас список сред разработки, не так ли?
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
По-моему, это здорово и очень технологично. И права, и банковская карта, и паспорт, и загранпаспорт (для Европы), и социальная карта, и ИНН — одной карточкой. Никто же не мешает иметь несколько банковских карт, кому не нравится выбор государства. Социальная карта москвича, к слову, привязана к Банку Москвы.
А у нас все отдельными документами — целую сумку надо таскать. Новое водительское удостоверение (права), например, вышло из формата кредитной карты, и строго говоря, не является международными. Т.е. еще один документ надо делать и возить с собой.
Но даже не это важно. Обидно, что МЫ такое же решение не получим, увы, еще очень и очень долго…
По-моему мнению, неправильно сводить выбор технологического инструментария для конфигурационного управления к удобству управления ветками. Есть требования инфраструктурные, есть процессные, есть секьюрные требования и т.д. Например, для CMM 3 необходима интеграция системы конфигурационного управления с системой управления изменениями (issue management, change management). Где-то требуется обязательный доступ через WEB, где-то высокие требования к ограничениям прав доступа к исходникам. А кто-то жить не может без интеграции со средой разработки. Не последнюю роль играют организационные факторы — наличие на рынке труда специалистов, знающих инструмент, а также наличие технической поддержки продукта в России.
Сама идея в результатах поиска разложить по секциям свойства искомого объекта мне нравится. Очень удобно сразу по запросу получить не просто ссылку на компанию, например, а адрес, телефон. Особенно эту функцию должны оценить пользователи мобильного интернета на КПК или смартфонах. Едешь на встречу с человеком в кафе, набрал название – сразу увидел адрес – и переходить никуда не надо по ссылке, а там еще в контакты и т.д. Театры опять же.
Достаточно информативно и полезно выглядят свойства товаров – фотоаппаратов, телефонов, телевизоров. Есть опасность перегрузить экран, поэтому я бы наверное желал видеть дополнительные секции только для первых 3-5 результатов поиска, тем более, что для товаров они наверняка будут одинаковые. То что кликать на такие ссылки будут чаще – это очевидно, т.к. создается ощущение, что именно на этом сайте все также профессионально и информативно представлено. Может сделать платную услугу ?!
Досадно, но очень непросто попасть в 1% информационных запросов, чтобы самому увидеть результаты поиска по новому.
В прошлом году мы решили серьезно заняться работой по государственным конкурсам и заявкам. Наняли человека с опытом, подписались на рассылку по всем конкурсам по всей России по направлению ПО, железо и услуги и начали работать.
Америку не открою, но для тех кто не в курсе, по федеральному закону 94-ФЗ от 21 июля 2005 года есть разные типы конкурсов: есть аукцион или торги, а есть вариант без торгов с котировочной заявкой, допускающая упрощенное оформление при сумме заказа до 600 т.р., хотя в Законе прямого упоминания об этих условиях нет.
Первое время, присматривались, приценивались, анализировали в основном неудачи, пытаясь вычислить процент маржи, с которым можно выигрывать с каким-то приемлемой частотой. Фронт работ был обширный: в день, минимум 10 конкурсов на ПО. В день получалось отправлять до 2 комплектов документов — немного, конечно, возни с документами очень много. Выбирали самые вкусные. Энтузиазма было море. Что удобно: как участник ты всегда получаешь протокол, где видишь победителя, разброс цен и т.д.
За первый месяц даже выйграли 2 котировочные заявки из регионов. Думали, вот оно, нашли жилу. А потом..., время идет, а результатов нет.
Большие аукционы стали просто игнорировать — документов море, затраты на нотариуса, отправку курьерскими службами и т.д., а выигрывает кто-то с 0 или отрицательной маржей. Дополнительно, все просят актуальную Справку по отсутствию задолженности перед бюджетами. Мы сверку в налоговой делали первый раз месяцев 5.
С котировками еще вроде был шанс. Работаем. Кстати, одна из самых распространенных причин снятия заявки — неправильно оформленная заявка. У нас был боец опытный и ошибся всего 1-2 раза. А вот по ценам пролетали регулярно. Разговаривали с дистрибьюторами, обсуждали снижение цен, привлекали производителей — никакого прогресса. Закономерности по ценам тоже никакой. Московский — не выйграли ни один.
Потом стало еще веселее т.к. направление все глубже и глубже уходило в минус. Маржу приходилось оставлять минимальную, скажем 3%, оплата всегда частями и вторую половинку можно ждать месяцами.Конечно всегда искали способы «войти в доверие», но это оказалось практически невозможным.
А потом допустили ошибку в спецификациях. Не уточнили какой Офис имелся ввиду — Профессиональный или Стандартный и… пришлось отказываться от победы. Автоматом попали в черный список неблагонадежных поставщиков на 2 года. Дальнейшие попытки стали бессмысленны. Это требование всех аукционов, хотя многие не смотрят.
К слову сейчас, ситуация технически еще ухудшилась из-за скачков курса доллара. Все аукционы строго в рублях, а закупаешься по текущему курсу валюты. С наценкой 3% — пролетаешь моментально, т.к. никакой «подушки» нет. А ведь кто-то участвовал в декабрьских аукционах...,
Много математики. Действительно, сегодня мало кто так глубоко задумывается над эффективностью зачастую готовых элементов интерфейса.
1. Это, конечно, так. Термин «Потребности» нужно понимать действительно в широком смысле. Однако на практике, функциональные требования настолько доминируют над сознанием и отношениями, что прочие «смыслы» зачастую остаются на бумаге. Более того, не функциональные требования часто проверяются только в первой версии, а для последующих уже нет. Вот, например, классическая заглушка для ФТР одного из наших проектов
8. Обеспечение доступности
Функционально-технические решения по обеспечению доступности не изменяются и соответствуют описанию в соответствующем разделе ФТР предыдущей версии N.N
2. Нет, не противопоставление. Скорее я хотел донести идею, что использование автоматических средств анализа исходного кода — это своеобразный недорогой «code review». Разумеется, просмотр кода опытными разработчиками или архитекторами может помочь выявить серьезные ошибки проектирования, например. Однако, использовать такой ресурс для более простых задач анализа текста программы, которые гораздо эффективнее и быстрее решает соответствующий инструмент — это расточительство времени и сил. Опять же я привёл примеры, когда альтернативы анализаторам кода просто нет.
Что касается использование анализатора кода в качестве средства обучения хорошим правилам программирования, то здесь я бы поспорил. Когда анализатор выдаст исчерпывающую справку о найденной уязвимости с подробным описанием возможных последствий, предоставит примеры того, как код исправить, укажет на строки кода, где эта уязвимость обнаружена — то это уже вполне можно считать элементом обучения.
Например, для C# из Kiuwan
Overload Equals method on value types
Description
For the value type «structure', default implementation of the method that determines the equality of two objects (Equals) habitually it will have a performance lower than a personalized implementation and because of this it recommends to personalize this method and Violation will appear when it is not like that.
Code
OPT.CSHARP.Csharp.OverloadingEqualsValueTypes
Reference
msdn.microsoft.com/en-us/library/7h9bszxx(VS.80).aspx
Violation code
Fixed code
3. Базовым результатом работы любого анализатора кода будет список найденных уязвимостей, ошибок, замечаний. Всё самое интересно начинается потом. Как работать с этим списком? Классификация, сортировка, группировка, приоритизация. Над этим слоем можно построить более общие отчеты по обнаруженным проблемам.
Выше — общая статистика по приложению
Выше — статистика по портфелю приложений, командам разработки или внешним исполнителям и многое другое.
Пример общего отчета анализа С# приложения.
И это только срез отчетов после одной проверки. А если процедуру производить регулярно, то появится возможность посмотреть на информацию в динамике — кто улучшает качественные характеристики, кто ухудшает, по каким показателям и т.д.
Еще на один момент я обращал внимание в статье — насколько важно обнаруженные уязвимости преобразовать в задачи. Здесь два аспекта — оценка сложность исправления и доставка задачи исполнителю. И то и другое, например, есть в Kiuwan — система помогает примерно оценить в часах, днях сколько нужно времен на исправление. Есть выгрузка в Excel. Есть интеграция с Jira / SBM. Наверное можно и с другими трекерами установить „рабочие отношения“.
Вот теперь это уже не только инструмент самообразования программиста, а полноценный инструмент контроля качества серьезной организации, как мне представляется.
4. Как известно, есть две парадигмы в отношении управления людьми. Или нужно исходить из того, что все сотрудники лентяи, бездари, халтурщики и т.д. или наоборот, что они все молодцы, болеют за дело, как за свое, пожертвуют своим временем и здоровьем ради проекта и т.д. Я обычно исхожу из „второй“, а получается как в „первой“. :)
5. Я даже скажу больше. Важно не только отбрасывать ложные срабатывания, но и „отключать“ целые типы уязвимостей, которые для ваших обстоятельств использования приложения, например, значения не имеют.
В Kiuwan пользователь может отключить отдельные найденные ошибки — »Mute" — и они больше не попадут в отчет даже при повторном анализе. Либо настроить свою модель качества приложений, повысив приоритет одних характеристик и снизив для других, что отражается и для расчета метрик и для поиска уязвимостей. Либо загрузить свои правила обнаружения дефектов.
Как-то так. Надеюсь, что ответил на ваши вопросы.
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
А у нас все отдельными документами — целую сумку надо таскать. Новое водительское удостоверение (права), например, вышло из формата кредитной карты, и строго говоря, не является международными. Т.е. еще один документ надо делать и возить с собой.
Но даже не это важно. Обидно, что МЫ такое же решение не получим, увы, еще очень и очень долго…
По-моему мнению, неправильно сводить выбор технологического инструментария для конфигурационного управления к удобству управления ветками. Есть требования инфраструктурные, есть процессные, есть секьюрные требования и т.д. Например, для CMM 3 необходима интеграция системы конфигурационного управления с системой управления изменениями (issue management, change management). Где-то требуется обязательный доступ через WEB, где-то высокие требования к ограничениям прав доступа к исходникам. А кто-то жить не может без интеграции со средой разработки. Не последнюю роль играют организационные факторы — наличие на рынке труда специалистов, знающих инструмент, а также наличие технической поддержки продукта в России.
Достаточно информативно и полезно выглядят свойства товаров – фотоаппаратов, телефонов, телевизоров. Есть опасность перегрузить экран, поэтому я бы наверное желал видеть дополнительные секции только для первых 3-5 результатов поиска, тем более, что для товаров они наверняка будут одинаковые. То что кликать на такие ссылки будут чаще – это очевидно, т.к. создается ощущение, что именно на этом сайте все также профессионально и информативно представлено. Может сделать платную услугу ?!
Досадно, но очень непросто попасть в 1% информационных запросов, чтобы самому увидеть результаты поиска по новому.
Америку не открою, но для тех кто не в курсе, по федеральному закону 94-ФЗ от 21 июля 2005 года есть разные типы конкурсов: есть аукцион или торги, а есть вариант без торгов с котировочной заявкой, допускающая упрощенное оформление при сумме заказа до 600 т.р., хотя в Законе прямого упоминания об этих условиях нет.
Первое время, присматривались, приценивались, анализировали в основном неудачи, пытаясь вычислить процент маржи, с которым можно выигрывать с каким-то приемлемой частотой. Фронт работ был обширный: в день, минимум 10 конкурсов на ПО. В день получалось отправлять до 2 комплектов документов — немного, конечно, возни с документами очень много. Выбирали самые вкусные. Энтузиазма было море. Что удобно: как участник ты всегда получаешь протокол, где видишь победителя, разброс цен и т.д.
За первый месяц даже выйграли 2 котировочные заявки из регионов. Думали, вот оно, нашли жилу. А потом..., время идет, а результатов нет.
Большие аукционы стали просто игнорировать — документов море, затраты на нотариуса, отправку курьерскими службами и т.д., а выигрывает кто-то с 0 или отрицательной маржей. Дополнительно, все просят актуальную Справку по отсутствию задолженности перед бюджетами. Мы сверку в налоговой делали первый раз месяцев 5.
С котировками еще вроде был шанс. Работаем. Кстати, одна из самых распространенных причин снятия заявки — неправильно оформленная заявка. У нас был боец опытный и ошибся всего 1-2 раза. А вот по ценам пролетали регулярно. Разговаривали с дистрибьюторами, обсуждали снижение цен, привлекали производителей — никакого прогресса. Закономерности по ценам тоже никакой. Московский — не выйграли ни один.
Потом стало еще веселее т.к. направление все глубже и глубже уходило в минус. Маржу приходилось оставлять минимальную, скажем 3%, оплата всегда частями и вторую половинку можно ждать месяцами.Конечно всегда искали способы «войти в доверие», но это оказалось практически невозможным.
А потом допустили ошибку в спецификациях. Не уточнили какой Офис имелся ввиду — Профессиональный или Стандартный и… пришлось отказываться от победы. Автоматом попали в черный список неблагонадежных поставщиков на 2 года. Дальнейшие попытки стали бессмысленны. Это требование всех аукционов, хотя многие не смотрят.
К слову сейчас, ситуация технически еще ухудшилась из-за скачков курса доллара. Все аукционы строго в рублях, а закупаешься по текущему курсу валюты. С наценкой 3% — пролетаешь моментально, т.к. никакой «подушки» нет. А ведь кто-то участвовал в декабрьских аукционах...,
Алексей Ионин