• beskov

МСК — Семинар «Требования к качеству ПО: Профили качества»

Я, Денис Бесков, организую серию семинаров
«Как формулировать требования к внешнему качеству ПО»

В популярной литературе по требованиям, статьях в интернете,
стандартах и на конференциях можно встретить списки видов
нефункциональных требований, в частности, атрибутов качества ПО,
которые могут быть полезны в ИТ-проектах.

В то же время у каждого слушателя и читателя остаётся вопрос
«сколько вешать в граммах?», т.е. как измерять конкретное требование —
например, юзабилити или масштабируемость и
как выбирать конкретные значения требований в цифрах.

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

Представляемая модель требований охватывает:
* 4 уровня качества;
* 12 атрибутов качества;
* 20 показателей качества;
* 14 классов систем и соответствующих профилей.

Участники семинара получат раздаточные материалы с шаблонами и инструкциями.

( Collapse )
sunny

Приглашаем принять участие в голосовании и выбрать лучшую статью по применению СУТ 3SL Cradle

Приглашаем проголосовать за лучшую статью!
Статьи-участницы конкурса по применению профессиональной системы управления требованиями и проектированием 3SL Cradle опубликованы. 
Приглашаем познакомиться со статьями и поучаствовать в открытом интернет-голосовании - выбрать лучшую статью, автору которой достанется приз зрительских симпатий.
Нам важно ваше мнение!
Ссылка на статьи
sunny

Возможность поработать с профессиональной системой проектирования архитектуры ПО и выиграть лицензии

Конкурс на лучшую статью

Призовой фонд 

Первое место - 1 лицензия на профессиональную систему управления требованиями 3SL Cradle-REQ (модуль Requirements Management) с поддержкой на 2 года. 

Второе место - 1 лицензия на профессиональную систему управления требованиями 3SL Cradle-REQ (модуль Requirements Management) с поддержкой на 1 год. 
Лицензии не ограничены во времени, поддержка дает возможность обновлять версии, получать помощь. 

Третье место - комплект книг по системному мышлению, анализу, управлению требованиями и проектированию

Матрица трассировки возможностей участников конкурса
http://saturs.ru/cradle/req-a-matr…

Полное описание, программа
http://saturs.ru/cradle/SATURS-3SL…

Страница конкурса
http://saturs.ru/cradle/req-a.html


. 
animated-1
  • 109

versioning

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

есть, значица, распределённая система, части которой обмениваются данными через pub-sub механизм. producer берёт rich C# object/data contract, бинарно сериализует, сжимает, шифрует, кладёт в queue. consumer, соответственно, читает, дешифрует, разжимает, десериализует и получает опять rich C# object, с которым удобно манипулировать.

теперь, предположим, мы выкатываем апдейт, в котором добавляем в наш data contract ещё одного data мембера. проапдейтить одновременно всех продюсеров и консьюмеров невозможно, их слишком много, у каждого своё maintenance window, и вообще.

поэтому надо как-то сделать, стандартным образом, чтобы не только новый consumer не ломался, когда читает старую версию объекта, но и старый consumer не ломался, когда читает новую.

сериализация - стандартная дотнетовская, с помощью BinaryFormatter, если что.

Update: всем спасибо, взял protobuf.

Ну что, приступим

Оригинал взят у vkorehov в Ну что, приступим
Разговоры это хорошо, но нужна уже сегодня практическая реализация распределенной системы планирования нового поколения.
В связи с чем создал проект:
https://github.com/vkorehov/PlanEc…

Для начала нужно определить архитектуру и потом можно переходить к реализации.
первый набросок:
1) Представить данные о планировании не в виде матрицы а в виде графа зависимостей (ациклического)
2) Различные плоскости планирования (например одна плоскость может согласовывать скорости производства, другая текущие количества к производству, еще одна запасы на каждом этапе производства)
3) Система должна состоять из распределенного ядра (написанного на языке C) и минимальной функциональности обхода и манипулирования данными графа (с гарантированной целостностью).
И также клиентских программ, которые будут прорабатывать различные варианты планов, оптимизацию и т.д.
Своего рода граф это база данных а программы это клиенты этой базы.

4) Защита ядра должна обеспечиваться шифрованием (по модели скайпа), ни один пользователь не может повлиять на правильности расчетов системы.
5) Интерфейс с ядром на основе минимальной реализации HTTP и интерфейса графа в стиле RESTfull API.

Архитектура ядра:
1) Реализация распределенных транзакций. Snapshot Isolation и принцип copy-on-write при манипулировании данными через REST API. Транзакции определяются сессией HTTP. Если нет сессии то доступ без транзакции REad-only.
2) Во время транзакции, репликация (повторение транзакции) минимум на 3 нодах. и 2-х фазовый коммит.
3) Partitioning и репликация данных между нодами (модель 2+2) репликации как во время транзакций так и периодические для подтверждения целостности, Система голосования(между 3-мя нодами) в случае повреждений целостности.
4) Базовые операции над данными должны быть не деструктивными. Например прибавление и вычитание показателя на число, но никак не присвоение нового значения. Такая архитектура позволит избежать конфликтов данных. Данные всегда можно интегрировать.
5) Транзитивные зависимости должны вычисляться автоматически при изменении показателя в данной транзакции. Т.е. изменили число яичниц и должен быть проход по графу до изменения числа яиц и т.д.
На практике возможен Threshold до которого нужно проходить, и соответственно коэффициент "нахлеста", сколько пере производить для для каждого нода.

Проект открытый, предложения приветствуются.
Программизм
  • beldmit

Аудит: продолжение

В продолжение этого вопроса.

Итак, данные мы храним в таблицах аудита, заполняем триггерами. Пишем transaction_id.

После чего возникает вопрос: как поднять предыдущее состояние.
Вариантов, собственно, 3.

1. ID транзакции
2. Время совершения операции
3. Значение из SEQUENCE (она есть, инкрементится в триггере аудита).

Как я понимаю, 2 - по сути ухудшенный вариант от 1, так как время фиксируется на момент начала транзакции.

Но вариант 3 тоже не дает желаемого результата: получим упорядочивание по времени начала транзакции, а не по времени завершения, как надо бы.

Есть способ сделать по-человечески? СУБД PostgreSQL, если что...

Update: Если подумать, то совсем правильный способ - SELECT FOR UPDATE перед выполнением апдейта аудируемых таблиц. Тогда, если триггер аудита - AFTER UPDATE, то вроде бы все получается.
Программизм
  • beldmit

Исторические данные

А как правильно организовывать данные в РСУБД, чтобы легко строить аналитические запросы для оценки динамики неких свойств в прошлом?

Вот, скажем, есть в базе сущность A со свойствами B, C, D, которые могут произвольно меняться владельцем этой сущности. А надо прослеживать динамику этой сущности с этим атрибутами.

То есть понятно, что можно можно триггерами фиксировать моменты смены этих атрибутов, всех вместе или каждого в отдельности. Плюс момент создания и удаления этой самой сущности (ну или другие моменты жизненного цикла). Но судя по длине получаемых аналитических запросов, которые потом все равно приходится сращивать каким-то скриптовым языком, решение не оптимальное - именно с точки зрения работы с РСУБД.

Или это еще одна задача, которая, как деревья, плохо ложится на РСУБД, и с этим надо смириться?
  • mshaman

Системная архитектура версия 2.0

Вопрос по информатике на ЕГЭ 2010.
Что такое системная архитектура?
Варианты ответов:
* организация и структура основных элементов информационной системы, имеющая принципиальное значение для функционирования системы в целом;
* набор взаимосвязанных моделей системы отражающих её структуру и поведения
* концепция системы на самом высоком уровне
* другое

Двусмысленность профессии системного архитектора в том, что основным предметом его деятельности является нечто, что довольно сложно увидеть. Ответом на просьбу показать архитектуру системы может явиться красочная картинка, набор UML моделей или же полстраницы текста. При всем уважении к профессии, позволю себе заметить неудачность всех предыдущих подходов к материализации такого артефакта как архитектура.

( Collapse )
  • mshaman

SOA в калейдоскопе кризиса

17.73 КБ
На протяжении нескольких последних лет, непонятных слов о сервис-ориентированной архитектуре было сказано много. Слишком много. Столько, что различить за ними реальные контуры данного подхода стало практически невозможно. Не знаю, воспринимались ли эти слова раньше, но практически не сомневаюсь, что теперь этот поток сознания никто точно не будет слушать.

И, тем не менее, перед SOA и программной архитектурой вообще открылось новое пространство возможностей.
( Collapse )
  • beskov

До «РИТ: Высокие нагрузки» осталось 6 дней

Конференция «РИТ: Высокие нагрузки» пройдёт 22-23 сентября в Москве, в «Инфопространстве».

На ней выступят ведущие архитекторы, разработчики и администраторы рунета, сотрудники компаний Яндекс, Рамблер, РБК/Медиа-Мир, Mail.ru, SpyLog, Masterhost, SUP Fabric и прочих.

Первый день будет посвящён правилам построения архитектур высоконагруженных систем, базам данных и коммуникационным системам.

Охват тем:
  • Что такое нагрузка? Как проектировать высоконагруженные сервера? Типовые проблемы и решения. Примеры промышленных архитектур.
  • Особенности MySQL и Postgres. Хранение данных в Живом Журнале, поискового образа рунета в Рамблере. Альтернативы Amazon S3.
  • Архитектура коммуникационных систем — Почта@Mail.ru, Instant Messaging.
Во второй день речь пойдёт о вопросах администрирования, тестирования, обеспечения безопасности, различных инструментах, а также примерах построения архитектур медиа- и поисковых систем.

Охват тем:
  • Организация защиты от DDOS-атак и перегрузки при наплыве посетителей.
  • Как хранятся и выдаются фотографии на проектах Яндекс.Фотки, Photofile, Netprint.
  • Как организуется выдача видео в Smotri.com, как сделать видеосервер своими руками.
  • Современные проблемы и способы их решения в поисковых системах Gogo.ru и Rambler.
  • Инструменты виртуализации, распределённых вычислений, организации локального поиска.
  • Мониторинг состояния большого парка серверов, организация нагрузочного тестирования и обеспечения производительности.
Полная программа 2-х дней: http://www.highload.info/program/