Архив за Сентябрь, 2013

Ответ на данетку

Пятница, Сентябрь 13th, 2013

В ходе обсуждения были даны ответы:
- остаток на счёте перед снятием не проверяется
- ошибка произошла при выполнении 3-й операции
- перед 3-й операцией на счёте $400
- в овердрафт не уходит (не может быть отрицательной суммы) ( - странно, что тогда происходит?)
- доллары с рублями не путает
- вместо отрицательной суммы 0 не подставляет
- других операций по счёту не было
- после 3-й операции происходило списание со счёта
- остаток - не отрицательное значение, не $0, не $400, не $300, не $500
- результат не зависит от архитектуры и выбранной СУБД
- ответ “близко” на “Записали отрицательное число в беззнаковую переменную”

Но правильный ответ так и не был получен.

– Ответ ————–

Код сервера приложений  (примерно такой):

{ остаток=остаток - сумма снятия;

if остаток < 0

then {сообщение об ошибке()}

else {выдать дньги;

сохранить новый остаток и операцию в базе данных}
}

Вроде бы никакого криминала нет. Проверка есть. Правда стоит она не до попытки совершения операции, а после. Все замечательно работает. Почти всегда.

Но есть такой прием, при котором с деньгами работают через целые переменные, храня в них центы. Счет исключительно дебетовый, почему бы не взять беззнаковое целое? Двухбайтовое для зарплатного счета маловато - максимальная сумма 655 долларов 35 центов, а четырехбайтовое в самый раз. Максимальная сумма - $42 949 672.95. Сорок два миллиона долларов - вполне достаточно. Но при выполнении кода отрицательного числа быть не может и проверка становится бессмысленной. Конечная сумма на счете: $42 949 672.95 - $100.00 = $42 949 572.95 Хорошая прибавка к старости.

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

Классификация требований по ГОСТ 34.602-89

Среда, Сентябрь 11th, 2013

Все ниже написанное – гипотеза, которую я выношу на обсуждение.

Внимание. Уровень сложности статьи  выше среднего (”Осторожно, вдумчивое чтение нижеследующего текста способно нанести непоправимый ущерб рассудку. Вас предупреждали.”).

———————————-

Не секрет, что у многих разработчиков ПО, работа по ГОСТ-ам вызывает отторжение. Не исключение и 34.602. С одной стороны, то что ТЗ должно быть – считают многие, но вот от попытки писать это ТЗ в соответствии с требованиями немного сносит крышу.

При внимательном изучение структуры становится понятно, что это очень высокоуровневый документ, состоящий из разделов, которые при других подходах принято оформлять отдельными документами. Так, например, раздел «5) состав и содержание работ по созданию системы» это явно документ планирования, ответственность за который несет руководитель проекта.

Примечание. 34-й ГОСТ вполне позволяет прописать в этом разделе 2-х или 4-х недельные итерации при создании ПО. Таким образом вы вполне можете сочетать ГОСТ с XP, RUP, SCRUM и т.д.

Но обычно ТЗ рассматривается в первую очередь как документ требований к разрабатываемому ПО. Вот на требованиях мы и остановимся подробнее.

Это раздел «4) требования к системе». И требования к составу и содержанию  этого раздела способны вогнать в ступор даже закаленного системного аналитика.

Вот несколько выдержек из требований к содержанию и оформлению:

    2.6.1. В подразделе “Требования к системе в целом” указывают:

требования к численности и квалификации персонала системы и режиму его работы;

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

2.6.3.7. Для организационного обеспечения приводят требования:

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

к организации функционирования системы и порядку взаимодействия персонала АС и персонала объекта автоматизации;

к защите от ошибочных действий персонала системы.

Причем здесь спецификация требований к ПО?

Но как только мы примем, что это требования не столько к ПО, сколько  ко всей совокупности изменения процесса, все становится на свои места.

Примечание. Это, знание похоже так осталось в 90-х.

Изменения процесса могут касаться изменений в:

  • исходном материале;
  • производимом продукте;
  • процессе преобразования материала в продукт;
  • средствах преобразования;
  • нормах деятельности;
  • навыках персонала.

Изменения со стороны исполнителя ТЗ, делаются за счет поставляемых этим исполнителем товаров и услуг. Вот к ним-то требования и выдвигаются. Если поставляются сервера, то возникают требования по электробезопасности и прочие. Если поставляются тренинги, то появляются требования к навыкам персонала и т.д.

Чего в 34.602 не хватает для более простого его понимания, так это раздела «Реестр поставки». Реестром поставки я пользуюсь несколько последних лет, и это экономит мне кучу нервов.

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

из книги «Записки автоматизатора»:

    … я сам столкнулся с ситуацией, в которой внедренцы забыли, что «нарезка» 80 различных видов рабочих мест потребует определенного времени и определенных ресурсов. …

Забыта услуга «Инсталляция ПО».

    … Также в методологиях поставщика никак не предполагается то, что система будет внедряться на месте старой, что потребуется переносить данные, что данные эти в различных модулях не должны противоречить друг другу и что система должна как-то жить в переходный период…

Забыта услуга «Миграция данных»

Также очень забавно обслуживать стенды «Образ заказчика» если не была создана служебная утилита «Обрезка БД» при 10ТБ базе. Собственно, и боевой стенд в таких условиях обслуживать довольно тяжело. И лучше бы на самом раннем этапе проекта заложить в реестр поставки утилиту «Компрессия БД». Ну и, конечно же, достаточно тяжело продавать современную банковскую систему, если в реестре товаров и услуг нет услуги «Обучение персонала».

Да что говорить, даже относительно простая система трекинга TrackStudio поставляется с:

  • услугой по настройке;
  • стандартными схемами;
  • руководством пользователя.

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

И не нужно давать написание ТЗ системному аналитику. Ответственность за написание ТЗ лежит на главном конструкторе. Впрочем, эта роль тоже осталась в 90-х. Но можно разделить эту ответственность на руководителя проекта и бизнес аналитика (маркетолога). РП и БА могут привлекать к написанию ТЗ (в зависимости от класса создаваемой системы): электрика (требования к электрообеспечению и электробезопасности), юриста, системного администратора (требования серверам и сетям) и т.д. А системному аналитику лучше  поручить написание частного технического задания на конкретное программное обеспечение из реестра поставки.

PS. В абзаце выше названия проектных ролей используются следующим образом:

  • Системный аналитик: инженер, который пишет спецификацию требований к ПО, используя UML, usecase, ER-диаграммы, и прочие способы записи требований к ПО.
  • Главный конструктор – отличный (выдающийся) инженер, сочетающий инженерную деятельность с административными функциями. Примерно соответствует главврачу в медицине. Как только ГК перестает выполнять инженерные функции, он перестает быть ГК.
  • Руководитель проекта – человек, в том числе, отвечающий за составление плана и календарного графика проекта.
  • Бизнес аналитик: инженер, который предлагает изменение существующих процессов организации. Описание изменений касаются: материала, продукта, норм деятельности и т.д.. Может работать с логическими диаграммами Голдратта, диаграммой «рыбий скелет» и прочими. Но не с UML и ER.

Данетка для разработчика

Вторник, Сентябрь 10th, 2013

В связи с прошедшим днем тестировщика и наступающим днем программиста (и тот и другой мои профессиональные праздники) предлагаю данетку.

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

—————————–

Идет тестирование банковской системы. Проверяются зарплатные долларовые счета. На счет положена сумма $800. Установлен лимит снятий $500.

1. Попытка снять $600 – отвергается системой

2. Попытка снять $400 – деньги сняты

3. Попытка снять $500 – деньги сняты

Вопрос: «Сколько денег осталось на счете?»

PS.  Дополнительный вопрос в стиле «Что, где, когда?»: почему лимит $500?