А как же оценка стоимости по функциональным точкам?
Т.е. даете оценку количества функциональных точек, даете на её основе оценку стоимости.
После выполнения работ подтверждаете реализацию задачи за отведенное количество точек. Если сделали больше, постараться уговорить заказчика оплатить доп работы, если меньше либо предложить доработку другого куска кода, либо сделать скидку.
Или к доработке это не применимо?
Нууу облачное ЭЦП подразумевает использование HSM, по сути токен, только для большего количества ключей. Ну и по существующим технологиям ключи ни при каких условиях HSM не покидают, так как ключи они генерируются и процессе подписания тоже происходит внутри, а наружу выходит только значение подписи.
Использование такого рода ЭЦП это мировая практика. Южная Корея давно применяет данный механизм, и как было где то на Хабре написано в Латвии так.
Возможно мне стоит еще подумать над формулировками и сделать их более формальными, т.е. определить желательный порядок слов. За это вам спасибо.
Кстати книга Алана Купера потрясающая (правда я её помню как «Психбольница в руках пациентов», но это не суть)
Немного не понял, на счет того, что нет фокуса места возникновения исключений. По мне так как раз у Коберна не понятно какие могут возникнуть проблемы при выполнении шага.
Так как читая основной сценарий не возникает вопроса, а что может пойти не так и только после того как читаешь полотнище дальше понимаешь, что все не так радужно как кажется на первый взгляд.
В своей форме я постарался сделать этот момент более наглядным.
После прочтения этой книги я тоже взглянул по другому на постановку требований, но мой опыт написания и чтения сценариев по описанному принципу, очень затруднителен и не удобен. Гораздо удобнее использовать таблицу.
Для себя я вывел таблицу из трех столбцов: в первый столбец я записываю "Действие" (обычно это основное действующее лицо), во второй "Ответная реакция" (обычно это система), в последний столбец записываю "Пояснения": ссылки на нормативные документы или другие ограничения, (например по размеру передаваемых данных или времени на выдачу результата) и обязательно перечисляю возможные исключения.
Таким образом я всегда понимаю «у кого мяч» (как выразился бы Коберн), и могу понять, с какими проблемами можно столкнуться при реализации шага.
По моему все эти вопросы довольно легко решаются, особенно про «кнопку не нажимал»
Да и на сколько я знаю в Южной Корее уже давно используются ОЭП, только УЦ является не какая-то кантора, а банк. Т.е. помимо денег вы доверяете банку хранение своей подписи, что кажется довольно логично, так как пользователь банка сможет подписывать любые транзакции своей ЭП и гарантом будет выступать банк. А банки при обнаружении фактов потери данных или злоупотреблением могут лицензию потерять и большое количество денег.
Странно, что заказчик требуют DOCX. Просто на сколько я знаю те кто требует по ЕСКД обычно госорганы. А гос органы должны требовать документы в соответствии с национальными стандартами, а в соответствии со стандартами принят только ODF.
Не обязательно, ведь можно будет на гоззаказе срубить еще больше бабала, что бы закрыть выявленные уязвимости и наделать еще других для следующего раза )
Ну и в принципе неравнодушные граждане-програмисты ведь могут рекомендовать изменения в коде для уменьшения возможных ошибок.
Спасибо за статью.
Прочел ваши предыдущие статьи и все равно не понимаю, почему у вас действия Актантов (или Акторов) в диаграмме активности не в виде дорожек, а так как вы представили? Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Можно будет еще раз немного поподробнее рассказать по данный выбор и не нарушает ли он нотацию?
По мне так второй вариант гораздо лучше, так как лучше видно кто за что отвечает… т.е. видно, что Слуга (А2) и Воин (А4) вообще сами по себе и ни с кем не контактируют и для лучшей читаемости их можно оттеснить в право, тогда никаких наложений по линиям не будет и будет виден процесс.
Знаю на сколько это сложно при больших объемах, но не проще ли руками? В конце концов вы таким образом теряете текст, который нужен для понимания того, что эта форма вообще из себя представляет.
Ну это не, что-то из ряда выходящее вот свежая новость из Узбекистана:
«В соответствии с постановлением Кабинета Министров Республики Узбекистан от 22 октября 2018года №847 начата реализация проекта по внедрению системы регистрации мобильных устройств в Республике Узбекистан.
В период с 9 ноября 2018 года по 22 января 2019 года проведен конкурс по отбору наилучших предложений по выбору исполнителя (поставщика) по проекту «Внедрение системы регистрации мобильных устройств
в Республике Узбекистан».
По результатам конкурса: участником, предоставившим наилучшее предложение по заявленным параметрам определена Компания «TTG» (Турция);
в случае, если с Компанией «TTG» договор на реализацию проекта не будет заключён, альтернативным исполнителем по проекту определена Компания «Invigo» (Ливан).»
То есть чем меньше совокупные затраты потребителя за все время эксплуатации изделия (не путать с гарантийным сроком), чем выше качество изделия при прочих равных его количественных характеристиках.
Т.е. при условии, что потребитель меняет телефон ежегодно, то китайский iPhone (опять при условии, что он год будет работать как надо) будет качественнее чем оригинал?
Прочел и пригорюнился :)
Занимаюсь разработкой документов (ТЗ, концепции, стандарты и т.п.), есть много требований (ГОСТы, ISO и т.п.) которым должны соответствовать эти документы. И вроде мои документы этим требованиям соответствуют (есть подпись нормоконтроля) и даже (иногда) в сроки укладываюсь, но вот чувствую, что можно лучше.
Но судя по содержанию статьи если моим результатом доволен заказчик то должен быть доволен и я, но часто заказчик тоже не понимает качественный результат я ему принес или нет. И из этого вытекает вопрос, как быть: расслабиться и делать как получается или страдать и делать как получается?
А самое тупое, что я не могу определить метрики того, что меня не устраивает в моей работе…
Ваше ТЗ используется только в проектах, которые вы сами же и разрабатываете или всё таки по ним работают сторонние разработчики?
Здесь больше интересно на сколько реализация отличается от поставленных задач.
Т.е. если разработчики не Вы, то не приходится ли Вам как разработчикам заданий еще оказывать услуги по «объяснению» определенных вами требований.
И если вопросов со стороны разработчиков нет, и реализация соответствует требованиям, то вы нашли интересный способ решения насущных проблем многих проектов :)
По моему вы перемудрили. Если нужно написать небольшое ТЗ, то все задачи которые вы описали легко решаются с помощью вариантов и сценариев использования. Которые понятны и заказчику и разработчику и тестировщику и благополучно могут быть записаны в раздел функциональные требования стандартного ГОСТовского ТЗ.
Вы можете вынести все сценарии в приложение к ТЗ и успешно их поддерживать в актуальном состоянии и дополнять по мере увеличения задач.
Т.е. даете оценку количества функциональных точек, даете на её основе оценку стоимости.
После выполнения работ подтверждаете реализацию задачи за отведенное количество точек. Если сделали больше, постараться уговорить заказчика оплатить доп работы, если меньше либо предложить доработку другого куска кода, либо сделать скидку.
Или к доработке это не применимо?
Использование такого рода ЭЦП это мировая практика. Южная Корея давно применяет данный механизм, и как было где то на Хабре написано в Латвии так.
Зачем поднимать панику?
Кстати книга Алана Купера потрясающая (правда я её помню как «Психбольница в руках пациентов», но это не суть)
Так как читая основной сценарий не возникает вопроса, а что может пойти не так и только после того как читаешь полотнище дальше понимаешь, что все не так радужно как кажется на первый взгляд.
В своей форме я постарался сделать этот момент более наглядным.
Он как никак автор метода :)
Для себя я вывел таблицу из трех столбцов: в первый столбец я записываю "Действие" (обычно это основное действующее лицо), во второй "Ответная реакция" (обычно это система), в последний столбец записываю "Пояснения": ссылки на нормативные документы или другие ограничения, (например по размеру передаваемых данных или времени на выдачу результата) и обязательно перечисляю возможные исключения.
Таким образом я всегда понимаю «у кого мяч» (как выразился бы Коберн), и могу понять, с какими проблемами можно столкнуться при реализации шага.
Да и на сколько я знаю в Южной Корее уже давно используются ОЭП, только УЦ является не какая-то кантора, а банк. Т.е. помимо денег вы доверяете банку хранение своей подписи, что кажется довольно логично, так как пользователь банка сможет подписывать любые транзакции своей ЭП и гарантом будет выступать банк. А банки при обнаружении фактов потери данных или злоупотреблением могут лицензию потерять и большое количество денег.
Ну и в принципе неравнодушные граждане-програмисты ведь могут рекомендовать изменения в коде для уменьшения возможных ошибок.
Прочел ваши предыдущие статьи и все равно не понимаю, почему у вас действия Актантов (или Акторов) в диаграмме активности не в виде дорожек, а так как вы представили? Ведь на сколько я понимаю принцип дорожек именно в разделении границ между взаимодействующими сторонами, ну т.е. в одной дорожке то что делает пользователь, в другой то, что делает система и т.п.?
Можно будет еще раз немного поподробнее рассказать по данный выбор и не нарушает ли он нотацию?
«В соответствии с постановлением Кабинета Министров Республики Узбекистан от 22 октября 2018года №847 начата реализация проекта по внедрению системы регистрации мобильных устройств в Республике Узбекистан.
В период с 9 ноября 2018 года по 22 января 2019 года проведен конкурс по отбору наилучших предложений по выбору исполнителя (поставщика) по проекту «Внедрение системы регистрации мобильных устройств
в Республике Узбекистан».
По результатам конкурса: участником, предоставившим наилучшее предложение по заявленным параметрам определена Компания «TTG» (Турция);
в случае, если с Компанией «TTG» договор на реализацию проекта не будет заключён, альтернативным исполнителем по проекту определена Компания «Invigo» (Ливан).»
На сколько мне известно так же рассматривается вопрос оплаты за регистрацию.
Т.е. при условии, что потребитель меняет телефон ежегодно, то китайский iPhone (опять при условии, что он год будет работать как надо) будет качественнее чем оригинал?
Занимаюсь разработкой документов (ТЗ, концепции, стандарты и т.п.), есть много требований (ГОСТы, ISO и т.п.) которым должны соответствовать эти документы. И вроде мои документы этим требованиям соответствуют (есть подпись нормоконтроля) и даже (иногда) в сроки укладываюсь, но вот чувствую, что можно лучше.
Но судя по содержанию статьи если моим результатом доволен заказчик то должен быть доволен и я, но часто заказчик тоже не понимает качественный результат я ему принес или нет. И из этого вытекает вопрос, как быть: расслабиться и делать как получается или страдать и делать как получается?
А самое тупое, что я не могу определить метрики того, что меня не устраивает в моей работе…
Здесь больше интересно на сколько реализация отличается от поставленных задач.
Т.е. если разработчики не Вы, то не приходится ли Вам как разработчикам заданий еще оказывать услуги по «объяснению» определенных вами требований.
И если вопросов со стороны разработчиков нет, и реализация соответствует требованиям, то вы нашли интересный способ решения насущных проблем многих проектов :)
Вы можете вынести все сценарии в приложение к ТЗ и успешно их поддерживать в актуальном состоянии и дополнять по мере увеличения задач.