vlnv's Friends
[Most Recent Entries]
[Calendar View]
[Friends View]
Below are the most recent 25 friends' journal entries.
[ << Previous 25 ]
| Thursday, November 12th, 2009 |
welgar
|
11:33a |
Над гнездом кукушки
Просят привлечь внимание к вот такой истории - неполитической, но довольно показательной. В Новосибирске Григория Е. после семейной ссоры родственники отправили в психушку. Причем сначала он под их давлением подписал согласие полежать там, а когда потом захотел выйти, оказалось, что это уже невозможно. Суд со многими нарушениями направил Григория на принудительное лечение, которое может длиться сколь угодно долго. Подробнее об этой истории с документами и комментариями.Просят перепостить. |
ailev
|
2:33a |
Информация жизненного цикла
Не могу удержаться, чтобы не процитировать поэзию из проекта документа ISO15926-7_TC184_SC4WG3_N2661: 3.3.2
lifecycle information
information about a possible individual, collected at any point in time during the lifecycle of that individual.
NOTE The definition of individual in ISO 15926-2 is: "A possible_individual is a thing that exists in space and time."
Информация жизненного цикла
информация о возможном индивиде, собранная в любой точке во времени в ходе жизненного цикла этого индивида.
ЗАМЕЧАНИЕ Определение индивида в ISO 15926-2 таково: "Возможный индивид -- это вещь, существующая в пространстве и времени" Просматривается три подхода к описанию разверток деятельности во времени: -- процессный (им. менеджмента качества и ISO 9000) -- проектный (им. PMI PMBoK и MS Project) -- жизненного цикла И последний подход явно пытается интегрировать все предыдущие, ибо в нем сходу вводится идея множественности описаний. Онтология ISO 15926 крутится вокруг жизненного цикла, и это приятно. Кстати, этот самый ISO 15926-7 задает онтологию ISO 15926-2 в формате логики первого порядка (representing EXPRESS entity types as unary predicates and EXPRESS attributes as binary predicates. reference data is treated as constant terms in the sense of first order logic). Выделить бы когда-нибудь себе недельку для складывания этого паззла: -- фактоориентированный подход, онтологии и нормы -- предметноориентированные языки и языковые капища -- программирование-моделирование-в-большом -- коллаборативный универсальный моделлер + SOA -- ситуативная инженерия методов: от деятельности к методам, от методов к деятельности -- системная инженерия и системное мышление: набор методов и их развертки во времени (модели ЖЦ) -- моделецентрическая системная инженерия (имитации и порождение) |
| Wednesday, November 11th, 2009 |
ailev
|
4:08p |
Пересмотры выделения ресурсов, пересмотры, и контрольные точки в жизненном цикле.
Вновь и вновь поднимается вопрос, что такое "пересмотры выделения ресурсов" -- текста самого ISO 15288 и поясняющих материалов явно не хватает для ответа на этот вопрос. Вот фрагмент из INCOSE SE Handbook v3.1 (кстати, следующая версия этого руководства выходит в феврале 2010, сейчас заканчивается проект по адаптации текста к ISO 15288:2008 -- и мы планируем затем перевод на русский. Так что нижеприведенный текст -- отнюдь не окончательный, но дорога ложка к обеду). | 3.2.2 Decision Gates | 3.2.2. Пересмотры выделения ресурсов | Decision gates, also known as control gates, are often called “Milestones” or “Reviews.” All decision gates are both reviews and milestones; however, not all reviews and milestones are decision gates. Decision gates address the following questions:
| Пересмотры выделения ресурсов, также известные как контрольные пересмотры, часто называются "контрольными точками" или "пересмотрами". Все пересмотры выделения ресурсов являются одновременно пересмотрами и контрольными точками, хотя не все пересмотры и контрольные точки являются пересмотрами выделения ресурсов. Пересмотры выделения ресурсов отвечают на следующие вопросы: |
• Does the project deliverable still satisfy the business case?
• Is it affordable?
• Can it be delivered when needed? | • Комплект поставки все еще соответствует организационной ситуации?
• Стоимость его приемлема?
• Может ли он быть поставлен тогда, когда он нужен? | | Decision gates represent major decision points in the system life cycle. They ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed and placed under coniguration control. | Пересмотры выделения ресурсов представляют главные точки принятия решения в жизненном цикле системы. Они обеспечивают, что новые мероприятия не делаются, пока ранее запланированные мероприятия, от которых зависят новые, не будут удовлетворительно закончены и поставлены под управление конфигурацией. |
| The primary objectives of decision gates are to: | Главные задачи пересмотров выделения ресурсов: |
• Ensure that the elaboration of the business and technical baselines are acceptable and will lead to satisfactory verification and validation.
• Ensure that the risk of proceeding to the next step is acceptable.
• Continue to foster buyer and seller teamwork. | • Обеспечить, что последующая доработка организационных и технических базисов приемлема и приведет к удовлетворительной верификации валидации.
• Обеспечить, что риск перехода на следующую стадию приемлем.
• Продолижть стимулирование командной работы поставщика и заказчика. |
| Decision gate approval follows review by qualiied experts and involved stakeholders and is based on hard evidence of compliance to the criteria of the review. Detailed information about the decision gate activity is provided in chapter 7.1. | Утверждение [решений] пересмотра выделения ресурсов следует за [техническим] пересмотром квалифицированными экспертами и вовлеченными [в проект] заинтересованными лицами, и основывается на строгом доказательстве соответствия критериям пересмотра. Детальная информация по мероприятиям пересмотра выделения ресурсов дается в главе 7.1 |
| There are at least two decision gates in any project: authority to proceed and initial acceptance of the project deliverable. The project team needs to decide which life cycle stages are appropriate for their project and which decision gates beyond the basic two are needed. Each decision must have a beneficial purpose; “pro-forma” reviews waste everyone’s time. Even in agile development frequent interaction with the customer may minimize, but not eliminate, the need for decision gates. The consequences of conducting a superficial review, omitting a critical discipline, or skipping a decision gate altogether are usually long-term and costly. | Существует как минимум два пересмотра выделения ресурсов в любом проекте: полномочия выполнять проект и начальная приемка комплекта поставки проекта. Команде проекта нужно решение, какие стадии жизненного цикла подходят для их проекта, и какие нужны пересмотры выделения ресурсов, кроме базовых двух. Каждое решение должно иметь выгодное назначение; "формальный" пересмотр -- это просто трата времени каждого [участника]. Проведение поверхностного пересмотра, опускающего необходимые дисциплины, или вообще пропуск пересмотра выделения ресурсов обычно ведет к долгосрочным и дорогостоящим последствиям. | | ... | ... | | 7.1.1. Decision Gates | 7.1.1. Пересмотры выделения ресурсов | | A decision gate is an approval event in the project cycle, suficiently important to be defined and included in the schedule by the project manager, executive management, or the customer. Entry and exit criteria are established for each gate at the time they are included into the project management baseline. Decision gates ensure that new activities are not pursued until the previously scheduled activities, on which new ones depend, are satisfactorily completed. Proceeding beyond the Decision Gate before the project is ready entails risk, as comically illustrated in Figure 7-1. The project manager may decide to accept that risk, as is done, for instance, with long-lead item procurement. | Пересмотр выделения ресурсов -- это утверждающее событие в ходе проекта, достаточно важное, чтобы быть определенным и включенным в график менеджером проекта, менеджером организации или заказчиком. Для каждого пересмотра выделения ресурсов в момент их включения в базис проектного управления устанавливаются входные и выходные критерии. Пересмотры выделения ресурсов обеспечивают, что новые мероприятия не предпринимаются пока предыдущие мероприятия, от которых они зависят, не закончатся успешно. Продолжение работ после пересмотра выделения ресурсов до того, как проект будет готов, связано с риском, как иллюстрировано в комиксе на рис.7-1 [в комиксе менеджер требует от инженера приступать к проектированию до того, как будут известны требования, чтобы никто не подумал, что ничего не предпринимается. Инженер вместо проектирования начинает читать газету, и замечает, что ему особенно нравятся проекты, заранее обреченные на неудачу]. Менеджер проекта может решить принять этот риск, как это делается, например, с заказом длинноциклового оборудования. | | The project business case issues of market demand, affordability, and realistic schedules are important decision criteria inluencing concept selection, and they should be updated and evaluated at every decision gate. Inadequate checks along the way can set up subsequent failures – usually a major factor in cost over-runs and delays. At each gate the decision options are: | Такие вопросы организационной ситуации проекта, как рыночный спрос, приемлемость цены и реалистичные графики являются важными критериями принятия решения, влиящими на выбор концепции, и они должны обновляться и оцениваться во время каждого пересмотра выделения ресурсов. Неадекватные проверки в ходе работ могут заложить последующие провалы -- [они] обычно важный фактор в перерасходе средств и задержках. В каждом пересмотре выделения ресурсов выборы таковы: | Acceptable: Proceed with the next stage of the project;
Or Acceptable with reservations: Proceed and respond to action items;
Unacceptable: Do not proceed; continue this stage and repeat the review when ready;
Unacceptable: Return to a preceding stage;
Unacceptable: Put a hold on project activity;
Unsalvageable: Terminate the project. | Приемлемо: переходить к следующей стадии проекта;
Или Приемлемо с оговорками: переходить и выполнить затребованные действия;
Неприемлемо: не переходить; продолжать эту стадию и повторить пересмотр, когда будет готовность;
Неприемлемо: Вернуться на предыдущую стадию;
Неприемлемо: заморозить мероприятия проекта;
Невосстановимо: закрыть проект. | | Upon successful completion of a decision gate, some artifacts (documents, models, or other products of a project cycle stage) have been approved as the basis upon which future work must build. If the project is large or long enough, or entails high risk, these artifacts are placed under coniguration management. | После успешного завершения пересмотра выделения ресурсов в качестве базиса, на котором должна строиться будущая работа утверждаются некоторые артефакты (документы, модели, или другие продукты стадии жизненного цикла). Если проект большой, или достаточно долгий, или подразумевает высокий риск, эти артефакты подлежат управлению конфигурацией. | Decision gate descriptions should identify the:
• Purpose of the decision gate
• Host and chairperson
• Attendees
• Location
• Agenda and how the decision gate is to be conducted
• Evidence to be evaluated
• Actions
• Method of closing the review | Описания пересмотра выделения ресурсов должны определять:
• Назначение пересмотра выделения ресурсов
• Организатора и личность руководителя
• Участников
• Место
• Повестку дня и как будет этот пересмотр выделения ресурсов проводиться
• Доказательства, которые будут оценены
• Действия
• Способ завершения пересмотра | | Decision gate approval must involve the necessary disciplines and stakeholders and must be based on hard evidence of compliance. One of the underlying principles for the agile development and extreme programming movements is to substantially reduce (but not eliminate) the frequency and elaborate (and they would claim pro-forma) content of decision gates for software development. Balancing the formality and frequency of decision gates is seen as a critical success factor for all systems engineering process areas. On large or lengthy projects, decisions and their rationale are maintained using an information management process. | Утверждение пересмотра выделения ресурсов должно включать необходимые дисциплины и заинтересованные стороны и должно быть основано на строгом доказательстве соответствия. Один из фундаментальных принципов движения гибкой разработки и экстремального программирования -- это существенно уменьшить (но не исключить совсем) частоту и проработанность (и они могут заявлять формальность) содержания пересмотра выделения ресурсов для разработки программных средств. Балансирование формальности и частоты пересмотров выделения ресурсов рассматривается как критический фактор успеха во всех областях практики системной инженерии. В больших или долгих проектах решения и их обоснования ведутся с использованием практики управления информацией. |
Современный способ, каким происходит доказательство в момент пересмотра выделения ресурсов -- "оценочное дело" (ISO 15026, assurance case), но я от. Отчетливо видно, что пересмотр выделения ресурсов -- это общий объект для менеджерской группы описаний и инженерной группы описаний. Менеджерская группа видит в нем контрольную точку, инженерная группа -- технический пересмотр. Осталось разобраться с пересмотрами и контрольными точками. Контрольная точка -- понятие управления проектами (менеджерское понятие). Вот определения из словаря системной инженерии ( http://pascal.computer.org/sev_display/index.action): | milestone | контрольная точка | | (1) a significant point or event in the project (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition) | (1) Существенная точка или событие в проекте (Руководство к набору знаний по проектному управлению (Рукодвоство PMBOK®) --четвертое издание) | | (2) a scheduled event used to measure progress. (IEEE 1058-1998 IEEE Standard for Software Project Management Plans, 3.3) Example: Major milestones for software projects may include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product delivery. Minor milestones might include baselining of a software module or completion of a chapter of the user manual. | (2) запланированное событие, используемое для измерения продвижения (IEEE 1058-1998 IEEE стандарт по планам управления проектами, 3.3)
Пример: Большие контрольные точки для проектов по разработке программных средств могут включать одобрения заказчика или менеджера, утверждение базиса спецификации, завершение интеграции системы и поставку продукта. Малые контрольные точки могут включать утверждение базиса программного модуля или завершение главы пользовательского руководства. |
Видно, что в контрольных точках принимаются менеджерские решения, но не происходит технических пересмотров. Большие контрольные точки затрагивают весь проект, а маленькие -- только его часть. | review | пересмотр | | (1) a process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval (ISO/IEC 24765:2009 Systems and software engineering vocabulary) | (1) процесс или заседание, в ходе которого продукт работы или набор продуктов работы показывается персоналу проекта, менеджерам, пользователям, заказчикам или другим заинтересованным сторонам для комментирования или утверждения. (ISO/IEC 24765:2009 Словарь системной и программной инженерии) | | (2) a process or meeting during which a software product is presented to project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval. (IEEE 1028-2008 IEEE Standard for Software Reviews and Audits, 3.5) | (2) (1) процесс или заседание, в ходе которого программный продукт показывается персоналу проекта, менеджерам, представителям пользователя или другим заинтересованным сторонам для комментирования или утверждения. (IEEE 1028-2008 IEEE Стандарт по пересмотрам и аудитам программного обеспечения) |
Технические пересмотры (review) -- наоборот, это детальное (обычно независимыми экспертами) рассмотрение технических решений, но они не подразумевают принятие менеджерских решений по итогам ("утверждение" продукта работы вовсе не означает того, что далее будут выделены ресурсы. Выделение ресурсов для следующих стадий -- это отдельное дело. А комментирование так и вовсе не подразумевает каких-либо "утверждений" или других менеджерских решений, кроме технических). Способы технических пересмотров могут быть разными, необязательно "оценочное дело", все зависит от целей таких пересмотров и выделеяемых на них ресурсов. Тем самым пересмотр выделения ресурсов -- это принятие менеджерских (т.е. выделение ресурсов!) решений по проекту в целом итогам технического пересмотра проекта в целом (и чаще всего этот технический пересмотр делается в формате "оценочного дела"). |
| Tuesday, November 10th, 2009 |
yulia_varra
|
11:37p |
Мои лекции в Израиле
Вчера состоялась моя первая обзорная лекция на темы тантризма, сексологии, ИМАГО-терапии и семейного консультирования, которая проходила в Бат-Яме в матнасе Ливорно. Организована лекция была моей подругой, которая много лет преподает йогу в этом матнасе по собственной методике, соединяя физическую, энергетическую и философскую ее составляющую. Люди занимаются у нее некоторые по 10 лет и говорят, что такого целостного подхода не находят нигде в другом месте. Являясь фанаткой моей книги "10 уроков тантрического секса", (книга довольно-таки трудна в прочтении непосвященному человеку:)), а также фанаткой лично меня, моя подруга решила еще организовать и регулярные тренинговые занятия под моим руководством для разных аудиторий.Желающие уже есть. Направления занятий будут такие. Тренинги для женщин: как стать лучшей любовницей для своего мужа, овладевание женской эротической биоэнергией, а также для одиноких - как найти мужчину своей жизни и выйти за него замуж. Тренинги для пар: возобновление медового месяца, методики индивидуальной семейной терапии (ИМАГО-диалог),способы решения конфликтных ситуаций. А также для продвинутых пар: тантрическое самосовершенствование и создание энергетического кольца пары... На первой лекции собрались в основном женщины, им безумно понравилось изложение затронутых тем, кто-то видел меня по ТВ, кто-то слушал по израильскому радио, все очень радовались посмотреть на меня в живую. Улыбнул вопрос-восклицание одной дамы: "Юлия, вы так много знаете об "этом", вы, наверное, очень счастливы в личной жизни!?" Я едва сдержалась, чтобы искренне не ответить: "Да, да вот уже как целых 4 дня!"... Я посмотрела на своего мужчину, и мы с ним рассмеялись, а моя подруга после нашего ухода начала причесывать, как положено, что Юлия Варра давно и счастливо замужем, (вот как раз это был ее муж). А вы что подумали? Такая известная женщина, инструктор по тантре и сексологии - разве может быть иначе?!:))"  |
v_alksnis2
|
4:23p |
|
welgar
|
9:25a |
Казнить нельзя мораторий
Ситуация с отменой смертной казни сложилась трагикомическая. Никаких формальных оснований для продления моратория нет: Протокол №6 парламентом так и не ратифицирован, своих законов на этот счет не приняли, Уголовный Кодекс не исправляли, суды присяжных в Чечне запускаются. При этом представители президента, правительства, Госдумы и Совета Федерации, а также всех остальных сторон в один голос убеждают Конституционный Суд подтвердить мораторий, приводя всевозможные аргументы, кроме юридических. По сути КС должен принять политическое решение об отмене смертной казни, которого за 10 лет так и не смогли принять ни парламент, ни президент. Сделав это (если только не найдет какого-то очень хитрого основания), он превысит свои полномочия, зато спасет рейтинги политиков. А если КС признает смертную казнь допустимой, Россия вылетит из Совета Европы. При этом Путин с Медведевым и депутаты будут рассказывать на Западе про "независимую судебную систему" и как их представители выступали в суде за мораторий, а в России будут рассказывать про глупый и злокозненный Запад, который не простил нам "суверенное решение" убивать своих преступников. Ну а сами будут тихо радоваться, что так красиво избавились от Европейского суда и ПАСЕ. Я сам, конечно, противник смертной казни и по моральным, и по прагматическим соображениям. Но сложно сказать, что опаснее для страны: применение высшей меры или принятие Конституционным судом политических решений, не основанных на законе. |
| Monday, November 9th, 2009 |
linux
[ budhaboy ]
|
8:03a |
Is there an easy way to track people who access files on an NFS share? I'd like to know who's accessed a file, and when. I'm hoping there's a way to get an http style usage log. |
| Sunday, November 8th, 2009 |
welgar
|
10:52p |
Милиция не дремлет
В Пензе проходят повальные задержания, допросы и обыски в квартирах оппозиционеров. Причина тому - пожар в офисе ЕдРа. Ума следователей центра "Э" хватило ровно на то, чтобы взять списки всех известных им членов оппозиционных организаций и начать всех трясти. Причем, похоже, больше всего досталось вполне мирным и законопослушным организациям: Обороне, Яблоку, Левому Фронту. Так, прошли или еще проходят обыски у оборонцев и яблочников: Артема Алемайкина, Павла Пономарева, Николая Зуева. У первых двух доблестные борцы с экстремизмом обнаружили и изъяли противогаз и топор. Дело пахнет терроризмом. А мне сегодня кинули в ящик повестку о вызове на допрос в качестве свидетеля к следователю по ОВД 1-го отдела СЧ СУ при УВД по ЮАО г. Москвы капитану Мелешиной Н.А. Дата и время допроса не указаны, а в графе "Дата и время выписки повестки" стоит просто "октября 2009 г." Естественно, ни на какой допрос по такму фиговому листочку я не пойду. Хотя интересно, какие ко мне могут быть вопросы у СЧ СУ УВД ЮАО... UPD: Судя по этому, 1-й отдел - это ОБЭП. Еще более странно... |
linux
[ bad_machination ]
|
12:12p |
Suppose I have a bunch of a particular kind of file with scrambled names (ABCD.jpg CDBA.jpg BBCA.jpg, etc) all from www.website.com/foo/ Suppose then I would like to wget replacements for all of the files. Who knows why? Maybe they're growing mold. Not the important part of the scenario. Is it possible to make a bash script using grep to get the file names and insert them into a wget command? I am not very familiar with bash or grep, so assuming this scenario is possible how might one do it? Thanks. -bmach |
yulia_varra
|
1:23p |
Звезда в шоке. Дело было так.
Я решила-таки снова рвануть в Израиль, чтобы закончить период залечивания душевных ран бурным сексом с чередой новых кандидатов в мужья! (как говориться, клин клином…). Предварительно найденных претендентов было в количестве шесть, я посчитала, что достаточно, (остальные обычно находятся прям там по ходу дела) и купила билет в Тель-Авив, надеясь, что моя грусть развеется, а печаль раcтает под лечебным израильским солнцем. Израильское солнце, должна вам сказать, и я не раз в этом убеждалась, лечит все, и даже больше… С моим израильским другом (моей безумной любовью летнего сезона, бросившим меня (читатели помнят)) мы иногда перезванивались, поскольку нас связывали деловые вопросы. Он вызвался меня подобрать из аэропорта, и я, подумав, согласилась, – все равно же надо было увидеться, - как по делу, так и поставить жирную точку на наших отношениях. Меня слегка подтрясывало, (сколько слез было из-за него пролито), но есть вещи, которых нельзя избежать, - и я всю дорогу тренировалась перед зеркалом изображать равнодушное лицо, мы же гордые… Меня встретили с букетом, поцеловали в щеку, погрузили в машину и повезли. Сижу. Общаемся. И тут я узнаю, что везут меня не ко мне домой, а к нему в дом, в тот самый дом, где каждый угол – воспоминания! Я не смогла сдержаться, и заорала, что ща выпрыгну из машины, пусть немедленно поворачивает ко мне, и в его дом я больше ногой не ступлю никогда и ни за что, и что он мудак, каких мало… Вы когда-нибудь смотрели голливудские фильмы? Сколько времени обычно требуется герою, чтобы уговорить героиню? Ха, я продержалась целых 15 минут(!), десять из которых заняли поцелуи (он-таки остановил машину). Ну а в перерывах между поцелуями, за оставшиеся пять минут я узнала, что он расстался со своей новой пассией, что она мизинца моего не стоит (конечно), что только я – навсегда, он наконец-то это понял, все решил, и везет меня к себе уже совершенно в новом качестве… Поверить было трудно, поскольку вот так неожиданно… Пока я охуевала вся в сомнениях от навалившегося счастья, мы доехали, влили в меня, трясущуюся, бокал вина, и упали в койку на целые сутки. Вы думаете, после череды оргазмов я поумнела и приобрела трезвую голову? Правильно. Абсолютно наоборот! Я встала с постели полная решимости бороться, в моей руке появился виртуальный томагавк, которым я пообещала переломать ноги любой рыжей суке, которая посягает на мое добро! Он клялся, что ломать ноги никому не придется, ее больше нет, и он любит только крашенных блондинок, а особенно одну!:)) Все слова, которые мужчина должен в такой ситуации сказать женщине, были сказаны. Мы торжественно под радио «Рэшет Гимель» (мое любимое) удалили все свои анкеты с сайтов знакомств. Надеюсь, что навсегда. Ну и в дополнение к происходящему, родился мой личный манифест, который публикую: Моим любовникам, прошлым и настоящим, а также тем мужчинам, кто хотел бы ими стать: ВСЕМ СПАСИБО! ВСЕ СВОБОДНЫ! После этого я еще накатила для храбрости, и уже смогла спуститься из спальни в салон к его родственникам и гостям на одно милое семейное торжество, где произошла немая сцена под девизом «и снова здравствуйте!» Я не знала, куда себя девать, от смешанных чувств стыда и торжества одновременно… Вот так прошел день, который изменил жизнь отдельно взятых двух человек в отдельно взятых двух странах. Вы думаете, так бывает? Сказанному – верить?.. |
linux_ru
[ poohpeer ]
|
10:24a |
OpenWRT
Установил фирмвер из сабжа на раутер Асус, но в его ГУИ нет такого понятия как Wan Connection Time (мне для статистики надо). Вопрос, как можно посмотреть в Линуксе из консоли конекшн тайм и где pppd хранит логи? Или может у кого будет другая идея, как следить за продолжительностью подключения? |
heviosso
|
1:40a |
It is astonishing just how much of what we are can be tied to the beds we wake up in in the morning, and it is astonishing how fragile that can be. Coraline, © Neil Gaiman P.S.: ![[info]](http://l-stat.livejournal.com/img/userinfo.gif) thenexus6 owns a russian translation of Coraline which says: "Интересно, почему то, что снится нам ночью и кажется таким значительным, вдруг исчезает, стоит проснуться?" |
ailev
|
2:06a |
Интересть
На Савеловском рынке семья дала мне десять минут на закупку гигабитного восьмипортового свитча D-Link и wi-fi роутера Linksys WRT54G2 v1. Решил остаться на протоколе g, хотя компьютер (по слухам) поддерживает и n тоже -- и роутер для n вдвое дороже, и выгоды непонятны, и наверняка с совместимостью что-нибудь будет не так. Уж ну его. Дома случилось три звонка провайдеру (отнюдь не все советы техподдержки оказывались верны), полтора часа плясок с бубном с беготней по трем разным комнатам, выкинутый сбивающий с толку настроечный диск к роутеру, смирение перед почему-то прямо в этот момент приспичившим установиться не менее 15 Windows Updates -- и жизнь, наконец, наладилась. В прошлом месяце я употребил интернетов на 4.5GB. В этом месяце наверняка вернусь к прежней норме. |
| Saturday, November 7th, 2009 |
ailev
|
1:05a |
vpri.org продолжает выкладывать тексты: масштабируемые идеи.
Vpri.org продолжает выкладывать новые тексты: - A Membrane with Parts: A new object model, Ted Kaehler
- Supporting Actors in COLA, Michael Fig
Крутейший рефакторинг идей: ищутся и изобретаются такие приемы программирования, которые работают в максимальном числе контекстов. Я вот думаю, что такое же нужно искать в деятельностном программировании: ситуативной инженерии методов. Нужны такие методы, которые были бы более-менее универсальны по отношению к целевой системе. Собственно, ISO 15288:2008 как раз такое и заявляет -- он работает независимо от размера системы, независимо от стадии жизненного цикла, независимо от уровня рекурсии в структуре системы. Это ключевой вопрос: компактность системы методов, компактность используемых методами описаний, пригодность одних и тех же приемов работы, типов артефактов, ролей для максимально широкого числа контекстов, максимально широкого числа ситуаций, максимальная масштабируемость. |
| Friday, November 6th, 2009 |
ailev
|
11:59p |
Как вскрыть ящик Пандоры
Большое спасибо всем, кто дал мне советы по пользованию разными вариантами VPN для прослушивания pandora.com ( http://ailev.livejournal.com/749592.html). Объявляем победителя: аноним, который посоветовал бесплатный и самый простой способ -- 1. скачать программу отсюда: http://www.hotspotshield.com/downloads/thank-you-RU/, 2. запустить и 3. слушать. Регистрация на заброшенном аж в 2007г. эккаунте Пандоры прошла в один клик, и тут же полилась музыка давным-давно созданного мной Rob Dougan Radio. Смею вас заверить, качество диджейства Пандоры.ком неизменно превосходит все мои ожидания. Как правильно пишут в интернетах, если у вас стоит баннерорезка (а у меня стоит Adblock Plus в FireFox), то никакой лишней рекламы вы не увидите. Tracert показывает, что ваш путь к счастью становится примерно на семь хопов длиннее, но это на глаз не слишком заметно. Вполне ожиданно отвалилась отсылка писем. Поставил музыку на паузу, сказал программе OFF, отослал письмо, сказал программе ON, снял музыку с паузы -- все продолжилось. Есть и неожиданности: Google для штатовского IP выдает другой порядок результатов поиска, хотя он меня вполне узнает и не требует никакого перелогинивания. Enjoy. |
welgar
|
10:50p |
Политпризывник-блоггер
Франак Вечорка, лидер молодежной организации Белорусского Народного Фронта, в январе этого года был с большим скандалом призван в армию. История очень напоминает мой призыв на время избирательной кампании Медведа, хотя с некоторыми отличиями (например, его догадались предварительно исключить из ВУЗа). Но в его случае власти не стали пускать обратных ход несмотря на все протесты, и Вечорка до сих пор отбывает службу в белорусской армии. А недавно он завел Twitter, который ведет прямо из войск. Пишет он, правда, по-белорусски и латиницей, но все равно интересно. Впрочем, я буду удивлен, если в скором времени у него не отберут телефон. |
welgar
|
2:43p |
ЕдРо вопасносте!
По личке ЖЖ пришло такое замечательное письмо от erics_trader, который был на днях забанен в ![[info]](http://l-stat.livejournal.com/img/community.gif) ru_politics за оффтопик и саморекламу (публикую с разрешения автора): Ко мне поступили сведения, что Вашей "рукой" я был забанен в сообществе "ру политикс" российского Живого Журнала.
Прошу показать мне пункт правил, на основании которого пользователь erics-trader (то есть я) был забанен до 11 ноября на вышеуказанном ресурсе. В противном случае неправомерное нарушение со стороны Администрации сообщества "ру-политикс" (чьим представителм вы и являетесь) будет вынесено на всеобщее обсуждение в блогосфере. Кроме того, о неправомерных действиях будет осведомлена ( в ближайшее время, вне зависимости от вашего решения) администрация российского Живого Журнала.
С уважением, Александр Осипенко, Активист ЦШ МГЕР, Москва. Все-таки, единороссы такие единороссы... PS: Этот юзер два месяца назад написал стихотворный "Ответ поляцкому гетто над историей" (грамматика автора сохранена): ( Read more... ) |
| Thursday, November 5th, 2009 |
ailev
|
11:44p |
Национальная библиотека справочных данных для ISO 15926
Сегодня было организационное собрание по национальной инфраструктуре для ISO 15926 (немного об этом: http://www.slideshare.net/ailev/iso-15288-iso-15926), собрались представители восьми организаций (а от нескольких организаций пришли по двое, а то и по трое), причем два человека участвовали через Skype-группу. На этом собрании были рассмотрены итоги первого в стране двустороннего обмена данных в стандарте ISO 15926 между двумя разнородными базами данных при помощи софта iRing ( http://www.youtube.com/watch?v=P224XeEonUM) и принято решение об институализации библиотеки справочных данных национального уровня. Решили оперативно ставить сервер, разворачивать на нем iRing Sandbox, и стучаться затем в WIP RDL Sandbox FIATECH+PoscCAESAR от имени Инфраструктуры интеграции данных Русского института системной инженерии. Ну, или Совета интеграции данных этого института (с именем отделения еще определились неокончательно, равно как и с персональным составом координаторов). После довольно бурной дискуссии было решено на первый раз ограничиться одной маленькой задачей: сделать templates для отечественной трубопроводной арматуры в объемах, достаточных для создания каталогов поставщиков. По мере сбора денег и других пожертвований порядок расходования средств таков: -- материальная инфраструктура (сервера, софт, администрирование) -- методические рекомендации по работе с iRing, учебники, технические рекомендации и прочее знаниевое обеспечение -- организационные расходы, продвижение, конференции и т.д.: набор организационной массы -- создание отечественных справочных данных (перевод ГОСТов в формат RDL, ибо никакая заграница нам в этом не поможет, а каждому отдельному поставщику это неудобно) Так что национальной инфраструктуре справочных данных по ISO 15926 в стране быть, и скоро. |
ailev
|
10:40p |
Жизненный цикл и его описание.
Понятие "жизненный цикл", равно то, как он описывается, вызывает множество вопросов -- как и любое другое важное понятие, в конечном итоге по-разному определяющееся разными заинтересованными сторонами в силу особенностей их деятельности, и поэтому (как и любое другое понятие, в отличие от "просто термина") позволяющее наладить коммуникацию между носителями онтологий разных предметных областей. ISO 15288:2008 (определения): Жизненный цикл -- эволюция системы, продукции, услуги, проекта или иного рукотворного объекта от замысла до прекращения использования.
life cycle -- evolution of a system, product, service, project or other human-made entity from conception through retirement.
Описание ЖЦ -- возможно организованный в стадии набор практик и мероприятий, связываемый с жизненным циклом, также служащий общим первоисточником для коммуникации и понимания.
life cycle model -- framework of processes and activities concerned with the life cycle that may be organized into stages, which also acts as a common reference for communication and understanding. ISO TR 24748 (пордаздел 3.2.1) пишет об этом так: Каждая система, вне зависимости от ее вида и масштаба, проходит жизненный цикл согласно некоторому описанию от своего изначального замысла до окончательного прекращения использования. Продвижение системы по частям этого описания, в какой бы то ни было последовательности и каким бы то ни было образом, называется жизненным циклом системы. Описание жизненного цикла, таким образом, — это концептуальная сегментация определения потребности в системе, ее реализации в виде продукции или услуги и ее использования, эволюции и вывода из эксплуатации. Описание жизненного цикла обычно сегментировано по стадиям, способствующим планированию, разворачиванию,эксплуатации и поддержке целевой системы. Такие сегменты дают упорядоченное продвижение системы через установленные пересмотры выделения ресурсов, что снижает риски и обеспечивает удовлетворительное продвижение. Основной причиной применения описаний жизненного цикла является потребность в принятии решений по определенным критериям до продвижения системы на следующую стадию.
Every system, whatever the kind or size, follows some life cycle model from its initial conceptualization through its eventual retirement. The progression of a system through the parts of the model, in whatever sequence or manner, is called the system's life cycle. The life cycle model, then, is a conceptual segmentation of the definition of the need for the system, its realization as a product or service, and its utilization, evolution and disposal. A system life cycle model is typically segmented by stages to facilitate planning, provisioning, operating and supporting the system-of-interest. These segments provide an orderly progression of a system through established decision-making gates to reduce risk and to ensure satisfactory progress. It is the need to make a decision to specific criteria before a system can progress to the next stage that is the most important reason for using a life cycle model. На практике происходит традиционная путаница между объектом и его описанием -- та же самая, что между "процессом" и "описанием процесса", "онтологией" и "описанием онтологии". Кроме того, есть огромные трудности представления жизненного цикла нематериальных объектов (например, сервисов или технологий), где есть трудности с пониманием границ самой системы, и уж подавно -- пониманием жизненного цикла этой системы и разведения самого жизненного цикла и ее описания. Так, технический проект "жизненный цикл технологии" (technology life cycle technical project, TLCTP) рабочей группы по управлению жизненным циклом INCOSE (INCOSE Life Cycle Management Working Group, LCMWG. Я член этой рабочей группы.) в качестве первого пункта области своих интересов приводит определения терминов "новая технология" (emerging technology) и "жизненный цикл технологии" (technology life cycle). Тем не менее, в этом проекте приводится косвенное определение, в котором жизненный цикл технологии по факту является процессом, включающим все деятельности, относящиеся к разработке потребностей в технологии, разработку и доведения до зрелого состояния новых технологий, переход к использованию технологии в продуктах и услугах, мониторинг полезности/устаревания, и "выбрасывание" технологий (“technology life cycle” encompasses all activities relating to the development of technology needs, the development and maturation of new technologies, the transition/insertion of technology into products and services, the monitoring of technology usefulness/obsolescence, and the “disposal” of technologies). В OMG SPEM 2.0 приводится следующее понимание жизненного цикла как процесса (самое начало раздела 9. Структура процесса): Одна из наиболее общих характеристик, находимая во множестве различных определений процесса в литературе -- это определение последовательности стадий и контрольных точек, выражающих жизненный цикл разрабатываемого продукта
One of the most common characteristics found within the many different definitions of process in literature is sequencing of phases and milestones expressing a lifecycle of the product under development Несмотря на то, что SPEM жестко разводит практики/методы и использование этих практик в качестве процессов, налицо путаница между процессом как описанием (life cycle model) и самим процессом (life cycle). Это нормальная практика, люди склонны путать символы и означаемое этими символами -- причем не только в речи, но и в действии (так, не задумывающиеся о подобных различениях люди регулярно целуют тряпку на палке, или две скрещенных дощечки). Даже OMG SPEM 2.0 (хвастающийся, что может описать любой жизненный цикл, также называющий его software process или delivery process) четко говорит, как описывается жизненный цикл: это процесс ( примененные методы/практики/дисциплины), расписанный по стадиям, их конечным продуктам, и указанием контрольных точек. Но тот же SPEM 2.0, говоря о "процессе поставки" (delivery process в терминах SPEM 2.0 и с учетом того, что этот жизненный цикл распространяется только на "проект", а не полный жизненный цикл системы), описывает не конкретный жизненный цикл, а "типовой" (класс жизненных циклов, которому в жизни будут соответствовать конкретные экземпляры): Процесс поставки является специальным Процессом, описывающим полный и интегрированный подход для выполнения отдельными типами проектов. Он описывает полный жизненный тип проекта от начала до конца и должен использоваться как типовой для проектов, идущих с походими характеристиками, как они определены для процесса.
Процесс поставки является Процессом, который покрывает жизненный цикл разработки от начала до конца. Процесс поставки должен использоваться, как шаблон для планирования и ведения проекта. Он обеспечиваюет полное описание жизненного цикла с предопределенными стадиями, итерациями и мероприятиями, которые были детализированы путем [указания] последовательности ссылок на содержание методов в структурах разбиения. Он определяется на основании опыта прошлых проектов или занятий, и/или лучших практик разработки или подходов поставки. Он определяет, что произведится, как эти единицы производятся, и требуемый персонал в форме интегрированных Структур разбиения работы, рабочих продуктов и команды. Например, некоторый инженер по процессам может определить альтернативные Процессы поставки для проектов разработки программных средств, которые отличаются по масштабам занятости и вовлеченного персонала, типу разрабатываемых программных приложений, методам разработки и используемым приемам и т.д.
A Delivery Process is a special Process describing a complete and integrated approach for performing a specific project
type. It describes a complete project life cycle end-to-end and shall be used as a reference for running projects with similar characteristics as defined for the process.
A Delivery Process is a Process that covers a whole development life cycle from beginning to end. A Delivery Process shall be used as a template for planning and running a project. It provides a complete life cycle model with predefined phases, iterations, and activities that have been detailed by sequencing referencing method content in breakdown structures. It is defined on the basis of experience with past projects or engagements, and/or the best practice use of a development or delivery approach. It defines what gets produced, how those items are produced, and the required staffing in the form of integrated Work, Work Product, and Team Breakdown Structures. For example, a process engineer can define alternative Delivery Processes for software development projects that differ in the scale of the engagement and staffing necessary, the type of the software application to be developed, the development methods and technologies to be used, etc. Так что нужно учитывать, что когда говорится об описании (model или description) жизненных циклов, чаще всего имеется ввиду описание не конкретного жизненного цикла, а типового жизненного цикла, и более того -- даже когда пропускается слово "модель", то тоже может иметься ввиду класс, а не его экземпляр. Тем самым в текстах по системной инженерии смешивается не только символ (описание, модель) и реальная жизнь, но и экземпляр (описания, модели) и включающий его класс. Тем не менее, все эти различения важны, когда речь идет о (компьютерном) моделировании жизненных циклов и порождении описаний проектов (например, в виде диаграмм Гантта) из моделей жизненного цикла. Поэтому слово "модель" хотелось бы зарезервировать для целей такого компьютерного моделирования, подразумевающего онтологическую точность, а слово "описание" использовать для всех остальных случаев рассказа о жизненном цикле (включая вариант опускания слова "описание"). Понятие "жизненный цикл" само по себе противоречиво (оно пришло из исследований по биологии, где взрослая особь дает потомство, как бы начиная новый "жизненный цикл" -- в технике же система потомства не дает, поэтому и "цикла" с замыканием кольца никакого нет). Также нужно понимать, что "жизненный цикл" системной инженерии существенно отличается от "жизненного цикла" советской инноватики и прочих "социологических" и "космических" исследовательских (а не инженерных) системных рассмотрений, не предусматривающих позиции менеджеров, принимающих осознанные решения по переходу между стадиями, и скоординированных инженеров, осуществляющих целенаправленную работу на каждой стадии (например, в работах Сазонова, Пригожина, Лапина и др. выделялось пять стадий инноваций: старт, быстрый рост, зрелость, насыщение, финиш или кризис. Другой пример -- жизненный цикл планет Солнечной Системы). |
| Wednesday, November 4th, 2009 |
heviosso
|
11:36p |
[ru] yazomg
Это даже еще круче, чем стенания по поводу газпромовского небоскреба. Идите, мол, бастуйте и увольняйтесь, я так считаю. Ни что так не поднимает настроение перед сном, как эти свободномыслящие, оппозиционно-настроенные массы в жж. |
linux
[ budhaboy ]
|
10:53a |
I've got a box running Hardy Heron I've been using as a file server. It's been acting a little flaky lately, and today for some peculiar reason when it reboots the machine seems to just die. I can log in remotely, the shares still work, I just can't access the box locally. When it does boot, just before the orange line gets to the end (on the splash screen) there's a peculiar system beep (i.e. not through the audio port), then nothing. I've tried restarting in recovery mode, and there don't appear to be any obvious problems... until you get to the login screen, and the video gets wonky and it appears to hang. I've tried booting from the live CD, but the options on what to repair aren't obvious... I strongly suspect a boot drive is failing, but what do I know? I'd like to keep all the configurations as I've got a rather large OS RAID I'd hate to reconfigure, as well as the server settings. Is there an easy way to back up the relevant boot drive settings remotely, replace the boot drive, and install a more recent version of ubuntu (while still retaining the settings)? |
| Tuesday, November 3rd, 2009 |
linux
[ zenten ]
|
9:33p |
[Fixed] Sound not working in VLC, mplayer, totem, works fine in madplay
So I just updated my Ubuntu install to 9.10 and sound seems to not work in any of my video players (yes, I checked the sound levels both in the programs and with the alsa mixer). I tried installing ubuntu-restricted-extras but all that did was turn all my videos blue. I tried also opening several mp3s in each of those programs and the sound does not play as well. However madplay can play those mp3s just fine. I also tried with a .ogg, the video players won't play it either. When I view the mp3 in totem with visualizations on it does seem to be basing them on the music, instead of just sitting there flat like it does with dead air. I tried running each program from the command line, but I didn't get any sound related errors. I can post the output if anyone thinks it would be useful. Any ideas? I tried searching through the forums for something related, but nothing popped up. EDIT: The issue was pulseaudio. Rather than trying to figure out what was wrong with it I just bypassed it and use ALSA now. Since I don't use any of the advanced stuff that pulseaudio does that should meet my needs. |
| Wednesday, November 4th, 2009 |
ailev
|
12:14a |
Архитектурные паттерны в системной инженерии
Несколько лет назад, когда зачинался PraxOS, я много писал про паттерны, как форму накопления методического знания (тогда я еще не был знаком с ситуативной инженерией методов, а форму накопления и хранения методического знания найти очень хотелось -- ну, я и обратился к "языкам паттернов"). Сегодня тесная связь паттернов, методов, практик, дисциплин и процессов уже очевидна. Хотя очевидна только сама связь: особенности же явно требуют пристального внимания -- взять хотя бы разделение MethodContent, Process и Practice в SPEM 2.0 как три ортогональных друг ко другу типа шаблона). В любом случае, литература по паттернам остается мне интересной. Вот, например, сегодня нашел книжку про применимость паттернов в системной инженерии -- Robert Cloutier, Applicability of Patterns to Architecting Complex Systems http://www.amazon.com/Applicability-Patterns-Architecting-Complex-Systems/dp/3836485877, 2008г. издания. А для тех, кто не хочет покупать эту книжку в бумаге, замечу -- это просто (похоже, урезанное на ненужные "приложения" с результатами опросов "в поле") издание диссертации 2006г., а диссертации обычно свободно лежат в Сети. Получите удовольствие: http://sse.stevens.edu/fileadmin/sse/academics/dissertations/Cloutier_Thesis_2006_PatternsAndComplexSystems.pdfСвежие мысли Robert Cloutier про паттерны в весьма вяло ведущемся его блоге: http://sepatterns.typepad.com/. |
| Tuesday, November 3rd, 2009 |
ailev
|
10:30p |
Ситуационная инженерия методов (situational method engineering).
Инженерия методов (method engineering, http://en.wikipedia.org/wiki/Method_engineering -- и нужно понимать, что, как обычно, из программной инженерии method engineering стремительно перемещается в системную инженерию) относится так же к методологии, как системная инженерия к системному мышлению (теории систем). Напомню: Harold Lawson предложил схемку, при которой инженерия -- это движение от придуманных концепций к их воплощению в реальных системах, а системное мышление изучает реальность и придумывает соответствующие ей концепции. Примером приложения инженерии методов к системной инженерии служит сам стандарт ISO 15288, который определяет (в соответствии с метамоделью ISO TR 24774) набор практик (методов, дисциплин, паттернов) системной инженерии в целом -- практики определения требований заинтересованных сторон, анализа требований, архитектурного проектирования и т.д. Затем в этом же стиле MFESA (Method Framework for engineering system architecture, формально текущая версия описана в книге: http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm и в подробной презентации: http://www.sei.cmu.edu/library/assets/mfesatutorialoneday20090420.pdf) определяет практики работ по архитектурному проектированию -- планирование и обеспечение ресурсами архитектурных работ, определение влияющих на архитектуру факторов, создание начальных архитектурных моделей, определение возможностей для повторного использования архитектурных элементов и т.д.. Легко можно предположить третий уровень уточнения, на котором описывается не только, что нужно делать, но и как нужно делать, например, определение возможностей для повторного использования архитектурных элементов (Task 4 MFESA) в заданном инструментальном окружении. На каждом уровне происходит детализация требований к выполнению работы. Так, ISO 15288 не требует никаких "оценочных дел" (это требует ISO 15026, в котором указано, как он связан с ISO 15288). Но вот MFESA конкретизирует требования "оценочного дела" и описывает методы/практики/дисциплины/паттерны, связанные с "делами архитектурного качества" (architectural quality case). Другой пример: практики жизненного цикла ISO 15288 на верхнем уровне, уточнение практики планирования проектов по Голдратту на втором уровне, и уточнение практики определения и документирования начальной длительности буфера проекта при использовании конкретного голдратт-совместимого софта управления проектами в условиях конкретной организации. Ситуационная инженерия методов (situational method engineering) имеет под собой ту идею, что метод выполнения работ нельзя задать заранее: каждая система уникальна, имеет свой собственный уникальный жизненный цикл, и поэтому каждая из систем требует для себя уникального метода работы. Утверждается, что какие-то кусочки/фрагменты методов все-таки можно осознать и хранить для повторного использования, но для конкретной системы из таких кусочков нужно "по ситуации" собирать ее уникальный метод, который будет продвигать эту систему по ее уникальному жизненному циклу, учитывая уникальную специфику этой системы и уникальные риски в соответствии с ситуацией. Тем самым утверждается, что людям нельзя дать универсальный метод, но можно дать "конструктор методов" с достаточным количеством этих кусочков/фрагментов, который позволит сплести (weaving) необходимый специализированный метод по потребности. Это означает, что "горбатую диаграмму" (hump diagramm) можно рисовать не только для применений (не путаем описание самой практики, и ее применение в развертке по времени!) первого уровня разбиения работ по дисциплинам/практикам/методам, но и для дисциплин/практик/методов второго уровня. Вот, например, классика жанра -- горбатая диаграмма набора методов (методологии) RUP для всего процесса:  Вот диаграмма для архитектурной работы по MFESA:  Пара определений (по мотивам онтологий MFESA и SPEM): Метод -- это систематический, документированный, осознанный (intended) способ, которым должна быть выполнена работа. В методе вполне могут быть шаги, но заранее неизвестно, в какой момент этот метод будет выполняться в конкретном жизненном цикле. Метод -- это единица повторной используемости. Процесс -- это способ, которым выполняется работа "в жизни". Можно сказать, что процесс -- это применение метода, происходящее-длящееся в конкретный интервал времени (и тем самым тесно переплетенное с применениями других методов). Процесс -- это всегда развертка во времени. Впрочем, описания процесса тоже могут быть повторноиспользуемы: тогда говорят о "шаблонах процесса" (в SPEM это capability patterns). Для создания "конструктора методов", используемого при ситуационной инженерии методов должны существовать: -- метамодель описания методов (правила описания кусочков методов и сборки из них методов более высокого уровня). -- метамодель описания жизненного цикла (правила описания применения методов в их развертке во времени, "от методов -- к процесссу") -- сами кусочки методов (говорят о репозитории методов) -- шаблоны жизненного цикла -- инструменты, позволяющие выполнять ситуационную сборку из кусочков и последующую доработку-уточнение целевого метода, включая указания о применении методов в различные моменты уникального жизненного цикла. В неявном виде ситуационная инженерия методов предполагается уже давно. Всякие "наборы процессов" типа CMMI, PMBoK, ITIL, да и набор практик жизненного цикла системной инженерии из ISO 15288 -- это как раз оно и есть. В каждом из этих текстов стандартов явно прописано, что предлагаемые описания процессов (т.е. практики, методы, паттерны, дисциплины, "области знаний") перед употреблением нужно дорабатывать согласно принятым в организациях приемам работы (второй уровень детализации) и выбранному инструментарию (третий уровень детализации). Число уровней детализации, конечно, может быть произвольным, к тому же на каждом уровне может происходить довольно сильное ветвление -- но существует рекомендация любому заинтересованному лицу разбираться только с тремя уровнями детальности. По факту активного использования ситуационной инженерии методов не происходило: предприятия не создавали методы "по потребности", а просто прописывали в своих инструкциях какие-то абстрактные "регламенты на все случаи жизни" и "обобщенные жизненные циклы". До примерно 2004г. не было разумных методов и "попсовых" инструментов для реальной ситуационной инженерии методов. На сегодняшний день ситуация существенно изменилась, хотя положение нельзя назвать удовлетворительным: -- существует огромное количество разных "наборов методов", они есть на все случаи жизни. -- все эти "наборы методов" описаны абсолютно по-разному, эти описания не придерживались никакой мета-модели. Есть совсем немного разных мета-моделей для ситуационной инженерии методов: ISO 24744, SPEM, OPEN/OPFG, ad hoc UML схема, SMSDM ("австралийские вариации" из http://ailev.livejournal.com/749986.html), неявная метамодель (когда люди "пишут единообразно" внутри себя, но не публикуют описания правил достижения этого единообразия), отсутствие метамодели. -- по факту существует только один вариант доступного полупопсового инструментария, подразумевающего обмен моделями методов: для метамодели OMG SPEM 2.0. Во всех остальных случаях приходится пользоваться результатами академических разработок, или какими-то "настройками" к разным моделерам общего назначения -- что явно не подразумевает обмена результатами работы по моделированию методов. В рассмотренном нами примере ISO 15288 придерживается метамодели ISO 24774, а MFESA придерживается метамодели OPEN (впрочем, OPEN -- это упрощенный вариант ISO 24774). Для OPEN есть огромный репозиторий кусочков методов (я писал уже о нем как о "родственнике PraxOS" -- http://ailev.livejournal.com/674073.html) с 1100 описаниями отдельных методов, выполненных в соответствии с метамоделью OPEN: http://www.opfro.org. Одна беда: никакого инструментария для поддержки создания кусочков методов (method authoring) для этого огромного репозитория нет, никакого инструментария для сборки нужных для данного проекта методов и описания их применения в ходе жизненного цикла системы тоже нет. Все "руками", и поэтому данная инициатива практически мертва на сегодня. Метамодель SPEM всем хороша, но у нее есть несколько существенных недостатков: -- в ней не предполагается многоуровневости описания методов, аспект-ориентированного многоуровневого плетения. Любой перескок с уровня на уровень (например, сделать шаг делом, а дело превратить в мероприятие) представляет собой проблему. -- нет совместимости с ISO TR 24774, а стандарты описания методов/практик системной инженерии используют именно этот подход (как ISO 15288, так и в какой-то мере MFESA. И это вряд ли изменится: сама проверка соответствия стандарту чаще всего проходит по ISO 15504, и ISO TR 24774 сам вырос из результатов дискуссий о том, как проверять выполнение методов в процессах. Авторов SPEM волновали совсем другие вопросы: их много больше волновало, как соединить описания методов с описаниями процессов) -- ничего не говорится про "оценочное дело" (разве что можно указать такой артефакт) Поэтому по факту вся ситуативная инженерия (чаще всего это разные вариации на тему RUP, облегченного агилизированного варианта OpenUP, eXtreme programming, SCRUM и прочих "софтверных процессов" -- см. http://www.eclipse.org/epf/) проходит сегодня с использованием SPEM-инструментария, а ситуативная инженерия методов соответствующей стандартам ISO "настоящей системной инженерии" либо вообще не происходит (что прямо противоречит требованиям этих стандартов), либо происходит "вручную", т.е. запредельно медленно и дорого. Отсюда выводы и программа ближайших работ: -- нужно создать русскоязычную терминологию для говорения о ситуативной инженерии методов. -- нужно исхитриться описывать методы/практики/дисциплины/паттерны, соответствующие метамодели ISO 24774 (т.е. стандарты практик системной инженерии) с использованием метамодели SPEM (создать специальный "метод описания методов") -- создать архитектуру репозитория кусочков/фрагментов методов PraxOS, пригодного для многоуровневого уточнения методов (в том числе методов системной инженерии, ибо есть и другие интересные для PraxOS методы -- например, дидактические методы, психотехнические методы и т.д.) -- создать начальную библиотеку методов PraxOS (ISO 15288, ICM, Голдраттовское планирование проектов, MFESА и т.д.) на русском языке -- внимательно отслеживать появление инструментария, соответствующего другим метамоделям и принять активное участие в международной инициативе SPEM 3.0, исправляющей самые вопиющие недостатки текущей метамодели (наверняка эта инициатива есть, ее только нужно найти и поддержать). -- предоставить полностью русскоязычный инструмент для ситуативной инженерии методов (т.е. гармонизированно перевести документацию/хелпы к EPF Composer). |
welgar
|
2:06p |
Топ-стоп
Яндекс объявил о закрытии рейтинга популярных записей в блогах - того самого "топа Яндекса". Объясняют они это тем, что рейтинг слишком затискали любители выводить ту или иную тему в топ. ...сервис всё больше становится не зеркалом, а инструментом для «выведения в топ» и дальнейшего распространия нужной темы в СМИ. Таким инструментом стали пользоваться все, кому не лень – от распространителей ссылок «помогите собрать деньги» до радикалов всех мастей. В результате радикалы одних мастей стали обвинять Яндекс в пособничестве радикалам других мастей, и наоборот. Привычку просматривать страницу рейтинга приобрели журналисты, выведение в топ стало платной услугой, и вот уже власть предержащие смотрят на рейтинг записей как на «глас народа». Все тролли и боты ЖЖ сегодня сменят юзерпик на траурный черный квадрат. А если серьезно, то такое объяснение мало что объясняет. Если бы Яндекс всего лишь одолели сомнения (вполне, кстати, понятные) в объективности и полезности топа, они могли бы просто его убрать куда-нибудь с главной страницы поиска. Ведь смысла закрывать такой уникальный для Рунета проект, наверняка приводивший немало посетителей и не требовавший особых ресурсов на поддержание, нет. Скорее всего, в Яндексе испугались опасных последствий того, что "неправильная" запись какого-нибудь "радикала" попадет в этот топ. И чтобы избежать таких политических рисков, от проекта отказались, оставив тем не менее API: т.е. "рейтинг-то вы можете составлять, но Яндекс уже за него никак не отвечает". В общем, похоже, это еще одно очко на счету российской самоцензуры. |
[ << Previous 25 ]
|
