Моя коллекция дорогостоящих багов пополнилась:
В итоговом отчете комиссии основной причиной инцидента называется "программный сбой, вызвавший одновременный перезапуск двух работающих каналов бортового вычислительного комплекса".
Отсюда: "Фобос-Грунт" погубили программисты
Это, как минимум, второй подобный случай с российским космическим аппаратом за последние несколько месяцев: спутник "Экспресс-АМ4" в августе 2011 тоже не долетел до нужной орбиты из-за бага.

Роскосмосу (или кто там у них главный по бумажкам) следует ввести крайне жёсткие стандарты обеспечения качества софта для космических аппаратов (брать пример с NASA), иначе вся отрасль рискует загнуться совсем и окончательно.

UPD: После этой версии очень скоро появилась новая (уже, наверное, седьмая по счёту): Роскосмос: "Фобос-Грунт" "сбили" заряженные космические частицы
Т.е. всё-таки в официальной версии в Роскосмосе остановились на "потустороннем" вмешательстве. Это  ведь удобнее всего.

На прошлой неделе позвали меня прочитать некую лекцию а-ля мастер-класс для студентов младших курсов академии Нестеровой. Тема была на моё усмотрение. Вобщем, я подготовил некую обзорно-развлекательную лекцию на тему как важен софт, сколько в софтовой индустрии проблем, и как они решаются с помощью программной инженерии. В результате получилась реклама моего предмета ТРПО, который я там преподаю для 4-го курса. Делюсь слайдами.

Занимательные статистические метрики, косвенно показывающие искусственную подтасовку голосов за ЕдРо вот тут:
http://oude-rus.livejournal.com/542295.html
Обратите внимание на следующее:
1. См. на форму графиков. Для статистики по всей огромной стране форму графика распределения следует ожидать нормальной. А здесь у ЕдРа правая часть задрана сильно вправо, а у остальных партий левый край вообще задран вверх.
2. Для статистики по всей огромной стране кривую следует ожидать гладкую, но см. на пилу у ЕдРа с пиками на красивых значениях.
Такие отклонения от нормального распределения явно свидетельствуют об искусственном вмешательстве в данные.

"...Федеральное космическое агентство (Роскосмос) и ФГУП "Космическая связь" официально признали, что телекоммуникационный спутник "Экспресс-АМ4" окончательно потерян. Обнародованы и первые итоги расследования: причиной названа ошибка в программировании системы управления разгонного блока "Бриз-М"..."
"...Размер страхового возмещения составляет более 7,5 млрд руб..."
Полный текст тут.

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

Побывал я на конференции Software People 2011.
К сожалению, смог придти только на первый день конференции, поэтому впечатление получилось размытым. Одного дня мало, и малый выбор докладов был в первый день. Место проведения в этот раз - зачёт.
Ниже я привожу краткий конспект о тех докладах, что я посетил. Это скорее отдельные мысли и идеи, которые были озвучены и которые показались мне интересными и я их записал, либо запомнил.

Нил Мейден (City University London)
Инженерия требований как творческое решение проблем: новые возможности для улучшения ваших методов. (Requirements Engineering as Creative Problem Solving: New Opportunities to Improve your Practices)
Речь в докладе идёт о творческом подходе в разработке требований для новых продуктов.
Предлагаемый подход включает проведение последовательных творческих сессий (workshops – участники собираются в одной комнате за большим столом, есть множество досок, компьютеры), на каждой из которых совместно анализируется текущее понимание будущей системы, возможные технические решения, анализируются аналоги похожих систем. На сессии высказываются и обсуждаются идеи, отбираются лучшие, записываются в виде модели Use Cases и сценариев ключевых Use Cases. Результаты записываются на бумажках и вывешиваются на доске или столе (storyboard).
Примерная длительность одной сессии – полдня. На последующих сессиях текущие результаты просматриваются, дополняются, перерабатываются, получая более проработанные Use Cases.

Ютта Экстейн (Независимый эксперт)
Agile через непрерывное планирование (Agile by Planning Continuously)
Доклад про важность планирования вообще и в Agile в частности.
План не важен, главное – планирование. («Фигня – война, главное – манёвры.»)
На каждой итерации происходит уточнение плана с учётом текущей ситуации и т.д.
Ничего нового в докладе не услышал.

Лассе Коскела (Reaktor)
Спецификация через пример (Specification By Example)
В докладе была высказана мысль, что некоторые вещи проще объяснить на примере, чем формально описать. И поэтому при описании требований следует давать конкретные примеры. Эти примеры дают лучшее понимание требований, служат для составления тест-плана, написания юнит-тестов, по ним проводится acceptance testing. В общем, примеры рулят, используйте их при описании требований.

Мадс Кристенсен (Microsoft)
Пишем HTML5 приложения, используя ASP.NET (Writing HTML5 applications using ASP.NET)
Доклад, который мог быть интересным только web-девелоперам. Демонстрировались новые возможности HTML5 и примеры кода на HTML5 и ASP.NET.

Сергей Авдошин (ГУ ВШЭ)
Формирование современных образовательных стандартов в области программной инженерии: факторы влияния
Доклад был настолько нудный и унылый, в худших традициях плохих лекций в вузе, что я не уловил его суть и основную мысль.
Рассказывалось про программы подготовки софтварных инженеров, приводилась зарубежная статистика.

Дмитрий Сошников (Microsoft)
Практическое функциональное программирование на F#: от облачного- и веб-программирования до телефона и игровой приставки
Я пошёл на этот доклад в надежде узнать, что есть такое функциональное программирование. Некоторое впечатление я составил, но не совсем понял, для решения каких задач стоит применять его и в частности F#, вместо традиционного императивного программирования. Демонстрируемые примеры были искусственны и не показательны, имхо.

Ольга Павлова (UsabilityLab)
Менеджеры и программисты: как перестать обижаться друг на друга?
Это был, пожалуй, лучший доклад в тот день, имхо. Речь шла о теме обид друг на друга, которые нередко возникают между начальником и подчинённым (слово программист в заголовке – это по большей части привязка к теме конференции). Объяснялось с психологической точки зрения, что происходит при обиде в голове у менеджера и подчинённого. Приводились рецепты по «лечению» и профилактике обид.
Кратко, рецепты по лечению:
- на вас обиделись: будьте внимательнее к обидевшемуся.
- вы обиделись: будьте самоироничны; помните, что никто вам ничего не должен; расскажите обидчику о своих проблемах.
Профилактика обид:
- всегда проявляйте уважение др. к др., менеджерам: говорите спасибо подчинённым.

В кулуарах мне также удалось послушать репетицию следующего доклада.
Борис Кириленко (CQG)
Модель навыка — техничный подход к нетехнической задаче
В докладе было рассказано, как можно применить конфайнмент модель навыка, разработанную российскими НЛП-шниками, для отбора кандидатов на вакансии. Эта модель включает в себя все возможные аспекты навыка, такие как умение, хотение, знания, способность получить результат, условия применения, картина мира, мотивация и т.д. В качестве навыка предлагается моделировать способность успешно исполнять задачи на вакантной позиции. Т.е. строится эдакая всесторонняя модель идеального кандидата, с которой сравниваются реальные по результатам собеседований.

Уже много лет я веду для себя эксельный файлик, в котором отмечаю уровень своей зарплаты в долларовом эквиваленте каждые полгода. По числам строится график. Сейчас он выглядит примерно вот так:

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

А вы хотите спрогнозировать, какая у вас будет зарплата (доход) в 2014 году? Возьмите шаблон, строящий такой график, здесь. Можно указывать з.п. и в других единицах.

В конце сентября довелось мне поучаствовать в довольно увлекательном мероприятии.
Для процессных менеджеров нашей компании был организован тимбилдинг силами одной из специальных контор. Мероприятие проходило в городе Коломна, куда нас привезли утром на автобусе.
 
Погода выдалась удачная. После завтрака и вступительной речи главного из организаторов нас разделили на три команды и выдали конверты с первым заданием.
 
В нашем конверте была карта Коломны и карточка с фрагментом карты, на котором был обозначен некий дом с номером и улицей, куда надо было придти. Мы нашли улицу на основной карте и направились туда. Но не так всё просто - по дороге обнаружился подвох. ( Read more... )

Мои общие впечатления от очередного СЕКРа:

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

Ниже я привожу краткий конспект о тех докладах, что я посетил. Это скорее отдельные мысли и идеи, которые были озвучены и которые показались мне интересными и я их записал, либо запомнил.

Рик Уивер (IBM Rational), "Оптимизация процесса разработки программного обеспечения: лучшие методы, практики и техники на сегодняшний день"

Важнейшие моменты, необходимые для оптимизации процессов, Рик перечисляет следующие:
1. Software measurements & metrics
2. Process definition
3. Collaboration
Стоимость разработки предлагается определять по формуле:
                Time or Cost of Build = (Complexity)^(Process) * (Team) * (Tools)

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

Андрей Уразов (Parasoft), "Программирование, ориентированное на качество"

Основными концепциями заявленного Quality Oriented Development названы следующие:
· Непрерывное обеспечение качества с самого начала разработки
· Автоматизация обнаружении дефектов

В конце всё свелось к призыву применять средства статического анализа кода и к рекламе продуктов Parasoft.

Джордж Шарков (ESI), "Разработка ПО: от исследований к бизнесу"

В докладе затронута тема о том, как исследовательский проект развить в продаваемый продукт или сервис.

Жизненный цикл перехода от идеи к продаваемому продукту выглядит вкратце так:
      Identify -> Develop -> Validate -> Consolidate -> Deliver

При этом здесь речь идёт в большей степени о том, как из множества идей отбирать и развивать стоящие, доводя их до продаваемого продукта. На входе в этот ЖЦ множество идей, которые на этапах ЖЦ исследуются, плохие отбраковываются, хорошие развиваются, строится прототип, который потом проверяется (пилотируется), на его основе формируется продукт, который поставляется (deliver) кастомерам. Идея может быть отбракована в этом ЖЦ на любом этапе. Только самые лучшие доходят до конца.

Ричард Соули (Object Management Group), "CISQ: управление качеством ПО становится дешевле"

Этот доклад снёс крышу смелыми заявлениями. См. здесь видео: http://cee-secr.org/lang/ru-ru/keynotes/soley/
OMG – контора, стандартизировавшая UML и CORBA.
Докладчик обещает появление стандарта для оценки качества продукта по нескольким уровням по аналогии с CMMI, который является стандартом для оценки качества процесса. Работы ведутся при участии SEI. При этом обещают, что по этому стандарту качество можно будет оценивать автоматически!

Луис Олсина (Национальный Университет Ла Пампа), "Интеграция качества, качества при использовании, юзабилити и опыта пользователей"

Модель качества софт. продукта ISO 25010:2010 дополнена критериями качества с точки зрения пользователя.
В последующем семинаре Луис рассказывал о том же самом, но подробнее, с примерами и с деталями.

Наталия Вегерина, Александр Липанов (Инфострой Ltd.), "Экспертная система анализа качества исходного кода программного обеспечения"

Рассказ про собственную поделку для измерения следующих метрик кода на .Net: сцепление, связность, нестабильность. И это с возможностью выдавать некие экспертные оценки о том, что надо сделать с кодом.

Александр Кондаков (INSPIREX Consulting), "Процессные инженеры: всё разнообразие видов"

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

Всеволод Леонов (Embarcadero), "Проблемы и направления развития инструментария RAD"

Было вкратце рассказано про продукты компании Embarcadero (включая купленный им Delphi и ко) и про стратегию их развития.

Михаил Кумсков (Люксофт), "Процессы и люди"

Развлекательный доклад человека с хорошо подвешенным языком. Мысль всего одна: Менеджмент на основе качества (по Демингу) очень хорошо соответствует методологиям Agile.

Сергей Архипенков (SPM (guild)), "Проблемы разработки ПО или проблемы управления?"

Ещё один развлекательный доклад человека с хорошо подвешенным языком. Куча нарочито вызывающих утверждений о том, что не надо разработку ПО сравнивать с разработкой инженерных продуктов, что процессы – кал, метрики – кал, CMMI – кал, тулзы не помогают, разработка ПО – это вообще гуманитарная дисциплина, а не техническая, т.к. основа успеха – это люди и их взаимодействие. Решение всех проблем программной инженерии представлено в виде 4P: Product, Project, Process, People.

Джей Дуглас (SEI), "Возврат от инвестиций в улучшение процессов"

В противовес предыдущему докладчику человек из SEI приводит статистику успешного внедрения CMMI 4-го и 5-го уровней с цифрами.
Средний ROI внедрения CMMI – 4:1. При этом все показатели улучшаются. Не записал все цифры.

Илья Сегалович (Yandex), "Опыт разработки в Яндексе: особенности процесса и ключевые технологии"

Доклад вызвал большой интерес. Было очень быстро и довольно много рассказано о жизни и работе в Яндексе. При этом чётких процессов там нет. У каждого отдела свои правила и регламенты. Есть устав менеджера, есть чеклист запуска проекта. Стратегия компании пишется каждый год. Идей развития у них куча, не знают куда их девать (у них есть внутренний лист рассылки, куда сотрудники отсылают свои идеи).