Кружки со стрелочками. Точно не помню, не сохранял, где видел не помню. Но заявка была крутая на анализ системы коррупции. По мне не более чем один из вариантов анализа рисков на уровне определения угроз.
Инженер по АСУ.
Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
ИМХО переводчик и публикатор (в одном лице) несет определенную моральную ответственность как за качество перевода, так и за выбор исходного материала.
Это очень сложный вопрос, ведь перевод может быть очень и очень разный. Одно дело полностью идентичный перевод, включая официальный, другое дело свободный авторский перевод. Пример из литературы — известно довольно много произведений русских классиков (включая Пушкина), по своей сути являющихся свободными авторизированными переводами, зачастую без указания откуда был взят первоисточник.
Такое впечатление, Вы пытаетесь изобрести «серебряную пулю» или «волшебную таблетку».
Скорее здравый опенсорс по связи теории и практики.
Как Вы себе представляете единый документ на все строения, которые будут построены — от частного дома до здания завода?
Технический регламент по общим требованиям вполне возможен.
Если сделали, к примеру, систему для сети аптек в городе N, то ее можно тиражировать и в других городах. Но для автодиллеров это придется переделывать под их специфику.
Самое забавное в том, что в обеих случаях главный бизнес-процесс абсолютно одинаков — Оказание услуг (торговли).
Нужна золотая середина — чтобы не тратить лишние ресурсы, да, общее что можно — это нужно вынести в общие требования. А для каждого случая уже смотреть и работать на месте и прорабатывать конкретные детали.
Помнится меня когда-то учили тому, что решением задачи является сумма общего рещения и решения при заданных начальных условиях.
Я в последнее время вообще предпочитаю примеры из сказки. habrahabr.ru/post/346582
Рассказ о реальной практике чреват обвинением в разглашении коммерческой тайны.
Для серьезной статьи одного практического опыта маловато будет. Даже простое описание того что делаешь требует дополнительных навыков и желательно опыта. :)
Немного в тему чем плох опенсорс. Вспомнилась история про форумный опенсорс. На одном форуме стали задавать довольно интересные вопросы. Я сдуру стал на них отвечать. Через некоторое время мне звонок на сотовый от одного знакомого. Сразу начал мне высказывать свое мнение о моем плохом поведении. Оказывается к ним на фирму пришли консультанты с бизнес-предложением. Для проверки их вшивости им дали несколько вопросов. Они пообещали завтра дать на них полные и подробные ответы и стали их задавать на профильном форуме. По мнению моего знакомого не надо на форумах консультировать тех, для кого консалтинг это бизнес. Может это и правильно! :)
Надеюсь Вы в конкурсе на простую НА (см. п. №3) поучаствуете? Пожалуйста, очень просим.
Тем самым Вы внесете существенный (или скромный, все от Вас зависит) вклад — как в борьбу с алхимией и наукообразием в ЕА, так и в сотворении научного архитектурного подхода (архитектурика) к описанию предприятия типа «домохозяйство».
Извините, разве «выпустить в бурю только то судно, которое справится с такой бурей с заданным допустимым уровнем риска» противоречит утверждению «не выпустить — которое не справится»? Мое точнее, оно учитывает и риск того, что катастрофа может произойти и с судном, которое может справиться с такой бурей. С принимаемым допустимым уровнем риска. Еще в древние времена моряки говорили: «Плавать по морю опасно, плавать по морю необходимо», что фактически является определением допустимого уровня риска.
Самое забавное в теме это то, что написание статьи или ее обсуждение на форумах тоже опенсорс. Правда не конкретных кодов, а мыслей, которые в дальнейшем можно использовать и в других целях.
Нет, суть риск-менеджмента это выпустить в бурю только то судно, которое справится с такой бурей с заданным допустимым уровнем риска. Абсолютная безопасность невозможна.
Вы ошибаетесь, рассматривая проблему из «окопа» рядового программиста. Смотреть надо с точки зрения высшего руководства и заказчика. Риск это все неопределенности, которые мешают достижению цели. Рисков очень много, например в Вашем случае как минимум (пишу не сами риски, а опасности, как их основу):
1. Ошибка в выбранном алгоритме достижения цели.
2. Ошибка в выборе оптимальной среды разработки.
3. Ошибка в выборе исполнителей.
4. Ошибки в компетенциях разработчиков.
5. Вероятность ошибок разработчиков.
6. Ошибка в выборе методов тестирования.
7. Ошибки тестирования тестировщиком.
И так далее и тому подобное.
Как Вам нравится такой метод минимизации действия риска сложных систем в которых обязательна работа трех различных каналов железа в которых обязательно ПО различных производителей? Это официальные требования для минимизации действия в том числе ошибок программирования. Иначе зачем было бы нужно устанавливать обязательное требование трех ПО от разных (подчеркиваю — разных!) производителей?
Сложнее для тех кто не знает как это делать. В самой количественной оценке рисков ничего сложного нет, желательна база статистического управления процессами. Статистика и теория вероятности — близнецы.
Для системщика по теме обсуждения нужны менеджмент, маркетинг, логистика, кибернетика, теория систем и много еще разной зауми, включая основы бухучета.
Не говоря уже о базовых матстатистике и теории вероятности. ПЛИС и многое прочее в реальности всего лишь практическое приложение к алгебре логики и прочему подобному.
Встречал попытку от одного украинского консультанта на уровне «рисовалки» с нестандартной нотацией.
Это очень сложный вопрос, ведь перевод может быть очень и очень разный. Одно дело полностью идентичный перевод, включая официальный, другое дело свободный авторский перевод. Пример из литературы — известно довольно много произведений русских классиков (включая Пушкина), по своей сути являющихся свободными авторизированными переводами, зачастую без указания откуда был взят первоисточник.
Скорее здравый опенсорс по связи теории и практики.
Технический регламент по общим требованиям вполне возможен.
Самое забавное в том, что в обеих случаях главный бизнес-процесс абсолютно одинаков — Оказание услуг (торговли).
Помнится меня когда-то учили тому, что решением задачи является сумма общего рещения и решения при заданных начальных условиях.
habrahabr.ru/post/346582
Рассказ о реальной практике чреват обвинением в разглашении коммерческой тайны.
Немного в тему чем плох опенсорс. Вспомнилась история про форумный опенсорс. На одном форуме стали задавать довольно интересные вопросы. Я сдуру стал на них отвечать. Через некоторое время мне звонок на сотовый от одного знакомого. Сразу начал мне высказывать свое мнение о моем плохом поведении. Оказывается к ним на фирму пришли консультанты с бизнес-предложением. Для проверки их вшивости им дали несколько вопросов. Они пообещали завтра дать на них полные и подробные ответы и стали их задавать на профильном форуме. По мнению моего знакомого не надо на форумах консультировать тех, для кого консалтинг это бизнес. Может это и правильно! :)
Лучше я Вам предложу статью с сайта мелкомягких по этому вопросу:
msdn.microsoft.com/ru-ru/library/ee914379.aspx
1. Ошибка в выбранном алгоритме достижения цели.
2. Ошибка в выборе оптимальной среды разработки.
3. Ошибка в выборе исполнителей.
4. Ошибки в компетенциях разработчиков.
5. Вероятность ошибок разработчиков.
6. Ошибка в выборе методов тестирования.
7. Ошибки тестирования тестировщиком.
И так далее и тому подобное.
Как Вам нравится такой метод минимизации действия риска сложных систем в которых обязательна работа трех различных каналов железа в которых обязательно ПО различных производителей? Это официальные требования для минимизации действия в том числе ошибок программирования. Иначе зачем было бы нужно устанавливать обязательное требование трех ПО от разных (подчеркиваю — разных!) производителей?
К сожалению только золотой червонец нравится всем без исключения. :)