1

О Сайте и Форуме / Идея: "вы выиграли в бинго!" http://en.wikipedia.org/wiki/Bullshit_bingo

« : 18 Февраля 2011, 11:18:50 »

Мне очень нравится сайт uml2.ru . Я считаю его одним из самых полезных, а участников - корректными, адекватными и говорящими по делу в большинстве своих постов.

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

Но всё же случается, что участники применяют сложные термины, расхожие выражения, "туманные" слова, англицизмы, неологизмы и другие "баззворды" не к месту, или просто слишком часто.

Чтобы участники этим не злоупотребляли - предлагаю реализовать на постах форума "bullshit bingo". Это такой режим, который участник может включить у себя в профиле. И после того, как включил:
1) "баззворды" у него начинают подсвечивается;
2) каждые, например, 10 "баззвордов", в ветке, которую смотрит участник, начинает отображаться пост "Бинго!".

Предположение о реализации - пре-процессинг записей, извлекаемых из БД, при формировании страниц форума.

Подробнее:
http://en.wikipedia.org/wiki/Bullshit_bingo
http://netlore.ru/Bullshit_Bingo
http://e-loto.altsoph.ru/

Чтобы сформировать список "баззвордов", каждый участник может запостить в эту ветку несколько "баззвордов", в употреблении которых заметил других и особенно себя.

2

Проектирование / Роль архитектора в различных методологиях: как лучше?

« : 07 Июня 2009, 23:22:02 »

<не уверен, что это сюда, но не нашёл раздела "сравнение методологий">

Вышел у меня на днях спор: кто такой системный архитектор?

Я говорил, что это как у нас, это такой программист-тренер, который (как минимум):

• владеет сразу всем кодом с высоты "от двух метров над землёй до фотографии из космоса"
• может читать требования
• может сказать, что из требований не реализуемо, что реализуемо, но требует существенных модификаций в архитектуре, а что отлично в архитектуру укладывается
• имеет свои планы технологического развития, и может сказать, что соответствует технической стратегии развития системы, а что противоречит
• умеет перевести требование "система должна..." в ряд задач "изменить компонент... чтобы он мог... рекомендуется реализовать там (такой-то паттерн, такой-то известный алгоритм, использование такой-то известной библиотеки)"
• порекомендовать на задачу программиста, прикинуть трудоёмкость
• во время проектирования и реализации с программистами свои решения обсуждать (именно обсуждать, а не диктовать в стиле "приказы старших по званию не обсуждаются").

Т.е. на входе у него новые требования, а на выходе новая архитектура и diff'ы между текущей архитектурой и новой архитектурой. А в самом лучшем случае - технические формулировки и очень примерные оценки трудоёмкости задач.

При этом архитектор может попросить уточнить требования, но сам их не диктует, аналитиками не управляет, с Заказчиками не беседует, roadmap единолично не задаёт.

А мне два человека, называющих себя, по-видимому, системными архитекторами, говорили, что архитектор - это вообще "всё-в-одном", в т.ч. владелец проекта:

• сам с Заказчиками и более высокими начальниками "на высоком уровне" общается
• "на высоком уровне, стратегически" определяет, что система будет уметь, из чего состоять, как работать
• выдаёт задачи аналитикам "опиши то так, опиши это этак"
• организовывает и согласовывает работу всех остальных.

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

Дамы и господа, как у кого разработка с точки зрения роли системного архитектора устроена? У кого к какому варианту склоняется, и что из этого получается?

3

Тестирование / Средства для тестирования

« : 06 Февраля 2008, 16:20:54 »

Господа участники,

Нужно ПО для тестирования, обладающее следующими характеристиками:
1) Позволяющее строить схему тестирования, лучше всего - каким-нибудь разумным способом, задавая дополнительные варианты для выбранных элементов, чтобы автоматизировать рутинную работу
2) Позволяющее детализировать её в тестовые последовательности
3) Позволяющее вести календарный план тестирования, ставить задачи, отчитываться
4) Позволяющее заносить информацию об ошибках, связанную с тестовой последовательностью/элементом схемы тестирования
5) Позволяющее импортировать требования и трассировать к ним элементы схемы/тестовые последовательности
6) Обладающее ограничением полномочий пользователей и разбиением работы по проектам
5) Freeware

Кто-нибудь сталкивался с такими инструментами?

4

Бизнес-анализ и Целеполагание / Есть ли у Вас опыт построения BPMS?

« : 21 Января 2008, 14:15:55 »

В статье Августа-Вильгельма Шеера "Хамелеон" говорится о неоднозначности термина "BPM".

Соответственно, и BPMS бывают разными. Например, их можно классифицировать на:
1) Business Process Management Systems, основное назначение которых в описании и анализе бизнес-процессов, например - ARIS Toolset, Business Process Visual Arcchitest, ILOG JViews BPMN Modeler;
2) Business Process Managed Systems, которые в большей или меньшей степени автоматически конфигурируются на основании уже описанных бизнес-процессов. Например: Unify, DocsVision, jBPM.

В системах класса (2) нужная часть описания БП:
- либо импортируется из системы класса (1), возможно, с использованием BPEL в качестве промежуточного формата;
- либо для этого предоставляется встроенное средство, напоминающее собой систему класса (1) с сильно урезанным функционалом.

Вопрос в следующем:
- Есть ли у Вас опыт в составлении концепций, подборке требований, проектировании систем класса (2)?
- В какой предметной области?
- Какие системы класса (1) использовались в качестве источника?
- Какие готовые компоненты использовались для создания встроенных редакторов БП?

5

Нововведения / Объектная прививка?

« : 14 Января 2008, 01:18:04 »

Да они сразу должны мылсить объектно, структурно как минимум. Почему не получается? Потому как такова система образования (по крайней мере на нашей кафедре). Что очень жаль.
Потому для них структурный код или ОО код - неестественный
А ведь стоит учесть еще и тот факт, что это 5 курс после сдачи квалификационной работы на бакалавра!!!
Alex, давайте не будем путать божий дар с яичницей. Все-таки курс у меня другой, задача подобная бух учету решается на 3 курсе в рамках соотвествующих дисциплин - смотрите мои опыты преподавания в разделе Обучения.
Прадва бухучета у них нет как предмета, что конечно сильно жаль.

Возможно, звучит как ересь, но объектное мышление (интересно, а как ещё можно мыслить?) и ООП - не одно и то же. Да и ООП имеет границы применения:
1) Дополнительная, по сравнению с процедурным программированием, сложность разработки и отладки должна быть оправдана. А ведь алгоритм прост и, судя по тому, что задачи изначально рассчитаны на Pascal, они замечательно решаются в процедурном подходе.
2) Разработка должна быть рассчитана на повторное использование - а ведь студенты знают, что их код после сдачи контрольной никогда никому не пригодится.

IMHO если так уж хотите увидеть ООП, нужно:
1) сказать: идеально работающее решение без ООП - максимум на тройку;
И/ИЛИ
2) потребовать, чтобы предметная область включала большое количество экземпляров сложных классов, у каждого из которых - разные свойства и методы (например, моделирование боя и большое количество различных боевых единиц);
И/ИЛИ
3) сказать, что для решения нельзя использовать язык, на котором простые задачи решаются простыми средствами (нельзя использовать PHP, Delphi или VB; можно использовать C++ и Java).

(1) и (3) я считаю искусственным навязыванием архитектуры, что может вызвать у программиста приверженность к необоснованно сложным решениям. Когда такие приходят - их приходится мучительно переучивать.

На всякий случай: ООП начал особенно хорошо развиваться, когда начали развиваться GUI. Действительно, рисовать GUI без объектов "глиф" сложно. А ядра всех ОС (хотя проскакивало что-то экзотическое...) и серверные части большинства "старых" приложений (в т.ч. SAP R/3) написаны без применения ООП, хотя ООП тогда уже было - при этом замечательно работают и неплохо развиваются.