?

Log in

Previous 5

Aug. 3rd, 2013


beskov

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

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

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

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

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

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

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

Read more...Collapse )

Nov. 20th, 2012

sunny

lanfleur

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

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

Jul. 22nd, 2012

sunny

lanfleur

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

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

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

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

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

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

Матрица трассировки возможностей участников конкурса

http://saturs.ru/cradle/req-a-matrix.html

Полное описание, программа
http://saturs.ru/cradle/SATURS-3SL%20Cradle%20REQ-A.pdf

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


Aug. 30th, 2011

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.

Aug. 22nd, 2011


vkorehov

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

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

Для начала нужно определить архитектуру и потом можно переходить к реализации.
первый набросок:
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 до которого нужно проходить, и соответственно коэффициент "нахлеста", сколько пере производить для для каждого нода.

Проект открытый, предложения приветствуются.

Previous 5