Cообщество

Группа исследователей из MIT представили программное обеспечение, которое способно динамически исправлять ошибки и уязвимости. Исправлять способно в любом коде, не обязательно в себе самом. Исходники не нужны. Только под Windows.
Оригинальный PDF c публикацией “Automatically Patching Errors in Deployed Software” Качать тут:

http://people.csail.mit.edu/rinard/paper/sosp09.pdf

Область практической применимости очевидна и огромна. “Deployed Software” это коммерческий софт. Утверждается, что лучше всего работает в кластерах, уязвимости обнаруженные на одном из хостов, автоматически накатываются на все остальные.

Идея такова:
это самое “Deployed Software” постоянно мониторится на подозрительную активность, например переполнение буферов, подозрительные передачи управления и прочее некорректное поведение. Это само по себе не новость, обычно после обнаружения такой активности приложение прерывается, при повторении - блокируется.

Тут на самом деле две проблемы:

• Если система high availability - ни о каком прерывании или блокировках не может быть и речи.
• Скорость латания дыр в коммерческом софте не велика - буквально через месяц программисты выпускают патч.

Новость тут в том, что ClearView, так называется система, обещает чинить баги и устранять уязвимости в реальном времени без рестартов и человеческого вмешательства.

ClearView сначала собирает статистику поведения во время нормального выполнения, они называют это “инвариантами выполнения”, затем отслеживает активность, при обнаружении подозрений автоматически патчит бинарный код пытаясь восстановить “инварианты выполнения”. Умеет сама тестировать различные варианты исправлений, накатывать и откатывать заплатки. Т.е. фактически пытаться держать систему в устойчивом состоянии, фильтруя input или блокируя и исправляя код.

Источники:
Можно почитать английский вариант тут http://www2.computer.org/portal/web/swebok/html/ch6#Ref2.2.2
Смотрите раздел Staffing
Или перевод http://sorlik.blogspot.com/
Скачать: Сопровождение (по SWEBOK) и см раздел Проблемы кадрового обеспечения* (Staffing)

Или читать перевод ниже:

Проблемы кадрового обеспечения (Staffing)
Данная тема касается вопросов привлечения и удержания квалифицированного персонала по
сопровождению. Часто, работа по сопровождению не выглядит привлекательной, инженеры по
поддержке воспринимаются как специалисты “второго класса” (в SWEBOK используется устойчивое выражение “second-class citizens”), что приводит к безусловному падению духа коллектива, отвечающего за поддержку систем.

Адрес: http://www.intuit.ru/department/se/inprogeng/

Информация о курсе
Единое целостное изложение основ программной инженерии, акцент на концепциях (ПО, процесс, модели и методологии), на различных методология разработки ПО (MSF, CMMI, SCRUM и пр.), а также на управляющих практиках (конфигурационное управление, тестирование, управление проектом). Существующий курс нуждается в существенном обновлении – реструктуризации на основе полученного опыта преподавания, замене CMM на CMMI, MSF 3.0 на MSF 4.2, выделении Web-приложений и особенностей их разработки и пр. Также планируется добавить примеры программных средств поддержки жизненного цикла ПО. В качестве последних предполагается использовать технологии Microsoft: TFS, Share Point, Microsoft Project, MSF. Кроме того, необходимо сделать курс максимально близким к стандарту Software Engineering Curriculum. Предполагается также организовать семинар, поддерживающий данный курс. Основным инструментом предполагается использовать карты памяти (Mind Maps) для обсуждения со студентами и контроля усвоения ими лекционного учебного материала.
Несколько слов о практикумах и семинарах, прилагаемых к данному курсу. Их задача – «прокрутить» лекционный материал через «сито» обсуждений, докладов и упражнений, основанных на картах памяти для лучшего усвоения. Серия таких экспериментов уже была проведена в прошлом году, на их основе была создана методика (опубликована в [1]) по активизации collaborative learning процессов и повышении активности студентов в изучении лекционного материала. Подобного рода поддержка лекционного курса крайне необходима, как показывает наш опыт, поскольку курс состоит в обсуждении проблем и способов их решений, с которыми студенты еще не сталкивались на практике. Мы хотели бы также дополнительно поддержать данный курс практикумами по средствам поддержки жизненного цикла разработки ПО на основе TFS и процессам разработки.

Цель
Суммация и систематизация сведений по программной инженерии у студентов последнего года обучения.

Лекции:

Прошу смотреть тут: http://www.intuit.ru/department/se/swebok/

Информация о курсе
В курсе представлено изложение ключевых понятий, методов и средств программной инженерии как деятельности, нацеленной на создание программных систем, отвечающих потребностям заказчиков, с соблюдением плановых сроков и бюджета.
Рассмотрены темы, актуальные для специалистов на пути от формулировки заказчиком требований до создания работоспособного и качественного программного продукта. Рассмотрены вопросы программной инженерии как инженерной дисциплины (применение инженерами не только теоретических методов и средств разработки ПО, но и стандартов, правил и методик управления разработкой ПО), а также вопросы проведения инженерных оценок качества, затраченных ресурсов, трудозатрат, стоимости и др.), основные процессы при создании программного обеспечения, среди которых такие ключевые разделы планирование (это анализ целей и задач, принципов реализации и управления планами и ресурсами), сопровождение (устранение найденных недостатков в ПО и внесение изменений как эволюционное развитие ПО ). Слушатели курса овладеют умением создавать системы с большими функциональными возможностями, управлять целями, сроками, ресурсами и ценой проекта, минимизировать затраты и стоимость.

Материалы курса на английском

Адрес курса: http://ocw.mit.edu/OcwWeb/Aeronautics-and-Astronautics/16-355JFall-2005/CourseHome/index.htm

Можно посмотреть http://www.uml2.ru/downloads/seminars/photo/2008-06-28-TrainingLabs/index.html

Видео ролики: http://traininglabs.rutube.ru/movies

Тему заголовка надо было назвать: "Total quality management " , но решил продолжить традицию.

В интернете по адресу : http://www.interface.ru/home.asp?artId=4743 нашел статейку по TQM.

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

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

В прошлом посте последняя картинка оказалось слишком мелкой.Поэтому публикую новую версию картинки.Прошу оставлять свои коменты

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

Вот составил диаграммку по материалам конференции по качеству.Автор материалов - Денис Бесков-Доронин.

В другой диаграмме - RUP

Тут все указывает на техническую сторону реализации , а на человеческий фактор нет.

Смотрим на http://www.enterpriseunifiedprocess.info/ новую диаграмму.

Видите?Появился - PEOPLE Management.Вот это уже лучше.Может еще что-то можно добавить?Я обратил внимания , что факторов способствующие успеху проекта , успешности компании - все больше и больше.И все взаимозависимо.

Собственно качество.Кто и как понимает качество?

Как оно измеряется?Какие показатели?

В практиках указанных выше можно конечно внедрить в компании , но зачем?Какая цена будет внедрения?В какой период они должны действовать?Что будет способствовать улучшению а что будет тормозить?

Адрес : http://www.intuit.ru/department/itmngt/isinst/

Информация о курсе
В курсе рассматриваются методологии внедрения информационных систем, состав и содержание выполняемых работ, методические основы управления проектами внедрения.
Технология создания продукта описывается в целом ряде стандартов (или методологий) внедрения, разработанных, ведущими поставщиками информационных технологий и систем. Основная черта таких стандартов — практическая направленность: они представляют собой проработанные, проверенные, многократно апробированные инструкции. Методологии содержат детальное описание фаз и этапов проектов внедрения, содержания и последовательности выполнения работ. В то же время, стандарты, предназначенные для различных систем (даже близких по классу), существенно различаются, поэтому курс содержит обзор различных методологий. Технология управления проектом носит более универсальный характер. В курсе рассматриваются основные процессы управления проектом в соответствии с известным и широко используемым стандартом PMBOK. Книга содержит шаблоны и образцы документов, рекомендации по формированию и использованию документов в процессе управления проектом внедрения информационной системы.

Цель
Курс предназначен для изучения методических принципов и технологических приемов управления внедрением информационных систем.

1.Методологии внедрения
Информационная система (ИС). Задачи и проблемы внедрения информационных систем. Назначение и состав методологии внедрения ИС. Содержание стандартов управления проектами. Концепции управления проектами. Участники проекта и их задачи. Общие особенности проектной деятельности. Окружение проекта. Организационная структура проекта. Основные типы структур организаций осуществляющих внедрение ИС. Организационная структура проекта
2.Стандарты управления проектами
Исполнение процессов MSF . Фаза выработки концепции. Основные задачи проектной группы на фазе выработки концепции. Фаза планирования. Основные задачи проектной группы на фазе планирования. Фаза разработки. Фаза стабилизации. Фаза внедрения. Дисциплины управление проектами. Дисциплина управления проектами MSF
3.Методология внедрения MSF (Microsoft Solutions Framework)
Понятие "ИТ‑решение". Модель процессов MSF. Фазы и вехи проекта внедрения. Модель команды проекта. Ролевые кластеры команды проекта. Масштабирование проектной команды. Организация исполнения проекта
4.Управление интеграцией
Понятие интеграции. Характеристики интеграции проекта. Элементы интеграционных процессов управления проекта: разработка Устава проекта; разработка предварительного описания содержания проекта; разработка плана управления проектом
5.Управление содержанием проекта
Процессы управления содержанием проекта. Построение иерархической структуры работ (ИСР). Словарь ИСР. Контроль за изменениями содержания. Управление содержанием. План управления содержанием проекта
6.Управление временем
Определение состава операций. Инструменты и методы. Список плановых операций. Параметры операций. Список контрольных событий. Определение взаимосвязи операций. Оценка ресурсов операций. Инструменты и методы Требования к ресурсам операции. Календарь ресурсов. Оценка длительности операций. Понятие длительности операций, периода времени выполнения операций. Разработка расписания. Инструменты и методы. Базовый план расписания. Управление расписанием. Отчетность о прогрессе проекта. Анализ отклонений по срокам. Управление расписанием
7.Управление стоимостью
Стоимостная оценка проекта. Классификация оценок стоимости. Типы оценок: сверху – вниз, снизу-вверх, параметрическая, по аналогам. Оценка стоимости операций. Вспомогательные данные для оценки стоимости операций. Разработка бюджетов расходов. Базовый план по стоимости. Управление стоимостью. Методы измерения исполнения проекта. Метод освоенного объема. Анализ показателей. Прогнозирование условий выполнения проекта
8.Управление рисками
Основные понятия и определения. Планирование управления рисками. Идентификация рисков. Оценка рисков. Качественный анализ рисков. Количественный анализ рисков. Планирование реагирования на риски. Мониторинг и управление рисками
9.Обзор методологий внедрения
Этапы проектов внедрения в методологиях On Target, Microsoft Business Solutions Partner Methodology, OneMethodology, Application Implementation Method (AIM). Цели и содержание этапов внедрения. Корпоративная методология внедрения
10.Стратегия развития информационных систем
Варианты стратегии развития ИС. Выбор варианта ИС. Технические критерии. Организационные критерии. Готовность предприятия к разработке стратегии развития. Стратегия внедрения ИС. Эффективность и риски. Классификация стратегий. Эффективности проектов

По этому адресу прочел статейку http://www.cfin.ru/management/people/definition_of_objectives.shtml

И мне захотелось поговорить на данную тему.Собственно как ставить цель , чтобы она была конкретной, измеримой, значимой,
достижимой и соотноситься с определенным сроком?Как ее создать удобной для восприятия , понимания?

Попробую предложить вариант.Скажем в среде Delphi.Web - разработку я трогать не буду , тк нет опыта.Но если кто хочет предложить свои варианты , то это будет здорово.

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

А он в указанных событиях пишит нужные процедуры.

Вот он видит форму.

И может посмотреть через список задач

Далее смотрит в обработчик событий

Тут видно.Скажем надо выполнить то-то.Если описание более сложное , то пусть смотрит такой-то документ.

Конечно надо еще учитывать какое программное обеспечение создается:Игры , Коробочные версии, веб-сайты и заказное ПО.

Вроде все перечислил

Когда: Чт, 29 Мая 2008 c 18:00 до 22:00

Регистрация:
http://livents.ru/msk/event/2008/05/29/seminara-kruglij-stol-reglamentatsija-i-avtomatizatsija-dejatelnosti/

Описание: Семинар – круглый стол «Регламентация и автоматизация деятельности»

При регистрации на семинар, указывайте свои ФИО в профиле, иначе Вы не попадете на семинар

Предисловие к представленному анонсу
Для систем автоматизации, в которых задействовано много пользователей с различными ролями написание хорошего ТЗ (работа системного аналитика) недостаточно для обеспечения работоспособности системы.
В многопользовательской системе необходима работа бизнес-аналитика, результатом которой будет, как минимум, схема процесса TO BE для написания ТЗ. В реальности большую многопользовательскую систему невозможно внедрить без регламентации деятельности людей вокруг системы. Львиная доля рисков внедрения системы для групповой работы сосредоточена именно в процессе создания регламентов (если угодно, технологии применения средств автоматизации), а так же в процессе внедрения созданных регламентов. Технические риски в таких проектах отходят на второй план, работоспособность или не работоспособность принятой (и зафиксированной в системе) организационной схемы полностью решает дальнейшую судьбу ИТ системы.
Семинар раскрывает сторону, которую ИТшники вообще никогда не считали своими activity, на деле же, из за отсутствия этих вещей терпят крушение многие проекты внедрения больших систем. При этом часты случаи, когда акты закрытия этапов подписаны, система пуско-налажена, но никто в ней не работает.

Целевая аудитория:
1. Бизнес-аналитики.
2. Системные аналитики.
3. Руководители проектов внедрения ПО.
4. Любой другой заинтересованный сотрудник любой Компании.

Что дает семинар:
Теоретические и практические знания по:
1. определению критичных для описания бизнес-процессов;
2. моделированию бизнес-процессов разного уровня;
3. формированию текстов регламентов на основе схем бизнес-процессов;
4. быстрому и неформальному согласованию регламентов;
5. построение мотивации сотрудникам, участвующих в бизнес-процессах.

Уровень подготовки: понимание необходимости регулярного управления с помощью разработки и поддержания в актуальном состоянии бизнес-процессов Компании.

План:
1. Вводная часть. Цели регламентации с учетом автоматизации деятельности. Основные определения.
2. Взаимоотношения бизнес-аналитика и программиста при автоматизации деятельности.
3. Технология регламентации деятельности с учетом автоматизации
Теоретическая часть:
Технология регламентации деятельности через моделирование бизнес-процессов.
Определение приоритетных мест для моделирования процессов.
Построение схем бизнес-процессов и поиск мест для автоматизации.
Создание ТЗ (форма, ответственность за составление и исполнение, сроки исполнения тестирование).
Построение регламента понятного для разработчика и исполнителя.
Создание документа для пользователя.
Внедрение процесса с учетом введения нового/измененного программного обеспечения. Эксплуатация и решения проблем при введении регламента с учетом автоматизации деятельности.
Как часто необходимо изменять созданные регламенты, в случае наличия изменений?
Практическая часть:
Отработка технологии построения регламентов.
Создание регламентов для пользователя на 1 странице?
4. Построение мотивации на основе построенных бизнес-процессов
Теоретическая часть:
Взаимосвязь результатов процесса и мотивации персонала. Определение ключевых показателей деятельности сотрудников, участвующих в процессе.
Практическая часть:
Совместная работа по определению мотивации для участников процесса (для данной работы берется уже сформированный регламент, см. п. 3).

Семинар – круглый стол рассчитан не более 4 рабочих часа. 1 перерыв на 15 минут.

Адрес для регистрации: http://livents.ru/event/2008/05/13/seminar-bpodbor-i-razvitie-komand-razrabotchikov-po-b/

Докладчик: Архипенков Сергей

Подробнее о докладчике:
Архипенков Сергей - руководитель проектов по совершенствованию процессов разработки ПО. Стаж в ИТ более 30 лет. Занимался созданием имитационных моделей сложных космических систем в Центре управления полетами. Руководил коммерческой разработкой ПО и проектами организационного развития в компаниях PriceWaterhouseCoopers, Luxoft, CBOSS. Выполнял проекты по заказу Европейского космического агентства (ESA), Даймлер-Бенц Аэроспейс (Германия), Boeing (США), ЦБ РФ, ОАО «Газпром». Является автором книг, статей и учебных курсов по информационным технологиям и управлению программными проектами.

Целевая аудитория:

1. Менеджеры проектов и лидеры команд разработчиков ПО
2. Руководители отделов и служб ИТ (позволяет глубже понять особенности разработки программных систем и учесть эту специфику при построении эффективных производственных процессов в подразделении).
3. Руководители HR служб ИТ-компаний (позволит управлять улучшениями в области подбора, оценки, развития и закрепления наиболее эффективных сотрудников).

Содержание семинара:

1. Представление курса «Руководство командой разработчиков программного обеспечения». Об авторе. Знакомство со слушателями. Содержание курса. Формат курса.
2. Группа или команда. Проблемы исполнения.
3. Разбор со слушателями «историй» из практики. «Программист Ашманова». «Делаем все по правилам!». «Хороший парень». «Тихоня». «Суперспециалист». Неприемлемые в команде патологии поведения. «Социальный аспирин».
4. Базовые принципы технического интервью. Мотивация начинается с приема на работу. Эффективное предприятие – это сервис. Цели и задачи интервью. Вступление. Что вы сделали? Что вы хотите делать? Какие у Вас есть вопросы? Что оцениваем. «Я могу предложить Вам…». Тесты по специальности. Советы кандидатам или Что еще оценивается в ходе интервью.
5. Аттестация. Вы должны нанимать сотрудника постоянно. Что оцениваем? Кто оценивает? Планируем карьеру. Сколько надо платить?
6. Заключение. Программист устроен просто.
7. Ответы на вопросы, обсуждение.

Ознакомился с GUI библиотекой от Usethics.Можно загрузить от сюда:http://www.usethics.ru/lib/indesign_library.html

Решил создать свою библиотеку.Которая могла помочь мне в работе и кому-нибудь еще.

Библиотеку которую на мой взглад будет полезна для аналитиков , программистов и юзабилистов.

Хочу представить версию v 0.1.Буду признателен за любой отклик.

Вот скриншот.

И шаблоны скачать можно тут:

http://narod.ru/disk/170627000/Gui_patterns.rar

Дата: Пт, 25 Апреля 2008 c 19:00 до 21:00

Место проведения семинара: Москва , Luxoft

Гибкие методы нового десятилетия: как избежать крайностей анархии и 17-томных тяжеловесных методологий прошлого.

Организаторы: AgileRussia и Учебный центр CareerLab ITONLINE GROUP

В апреле Россию впервые посетит Эдвард Йордон, признанный гуру в области управления софтверными проектами и программной инженерии, автор всемирно известного бестселлера «Путь камикадзе» (Death March).

Посещение БЕСПЛАТНОЕ. Количество мест ОГРАНИЧЕНО. Регестрируйтесь СЕЙЧАС

Адрес для регистрации: http://livents.ru/event/2008/04/25/edvard-jordon-besplatnij-seminar-gibkie-metodi-novogo-desjatiletija/

В разделе вопросов нашего сообщества Алексеева Ольга спросил:

Андрей, скажите, пожалуйста, а Вы с методологией RUP не сталкивались? Если да, то не могли бы поделиться впечатлениями? Изучаю сейчас вопрос, собираю отзывы практиков.

Вот что мы думаем по этому поводу:

В принципе знаком.Изучал ее в период внедрения на предприятии в отделе АСУ.

Изучили UML , роли.Но оказалась она очень тяжеловесной для нас.А именно дорогой.Руководству не смогли доказать целесообразность.Видимо была проблема в уровне зрелости предприятия.

Когда начинаешь работать над проектом(это может быть разработка , поддержка , внедрение) .То сразу чувствуется , что-то не хватает.Не хватает знаний.Проблема в нашей суровой действительности решается все за счет коммуникабельности сотрудника и порою плохо оплачиваем трудом.А если сотрудника взяли в условиях кадрового голода , явно необщительного?То что?Все приехали! Что будем делать?Мучаясь вопросами я полез искать в интернете и в swebok ответы по данному вопросу.И вот нашел, несколько пунктов .И думаю:"Жаль а у нас работает только один , максимум три пункта.Вот бы все у нас это работало"

Системы совместной работы(электронный документооборот) позволяют людям организовать виртуальную встречу, обсуждение, «мозговой штурм» и обмен знаниями. Участники создают новые знания за счет исследования и постепенного понимания, позволяющего «узнать почему» в проекте следует принять то или иное решение. Несмотря на то, что системы совместной работы могут использоваться на уровне всей организации или сообщества коллег, они часто применяются в рамках проектной группы для контроля версий, распространения информации и для уведомления о тех вопросах, которые могут повлиять на выполнение проекта . С помощью систем совместной работы можно получить знания, касающиеся создания решений, которые соответствуют контексту текущего проекта.

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

Системы управления инвестициями и портфелями служат для определения, планирования и контроля инвестиций. Этот инструментарий полезен для выбора и планирования будущих проектов с учетом потребностей организации. Руководители проектов используют знания, полученные в уже осуществленных проектах, в среде для разработки и документирования обоснований (что позволяет «знать почему»), для того чтобы понять, стоит ли организации продолжать вкладывать средства или риски растут неадекватно быстро.

Карты знаний помогают находить людей, обладающих требуемым опытом, что важно, когда знания можно получить только в результате «мозговых штурмов» и бесед с экспертом, а также когда их нелегко документировать. Сложная природа управления программным проектом предполагает, что для решения некоторых проблем лучше прибегать к интерактивному подходу.

Социальные сетиформируют отношения, способствующие обмену знаниями путем общения, обсуждения и использования общих практических методов. Менеджеры программных проектов и члены проектных групп могут, во многих случаях, за счет неформальных отношений обмениваться знаниями более эффективно, чем это позволяют обширные репозитории знаний. Люди получают новые знания и могут «узнать почему» следует сделать так, а не иначе, в личных беседах со специалистами (или наставниками) в определенных профессиональных областях.

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

Системы управления проектами могут помочь планировать, определять сроки выполнения и отслеживать прогресс в выполнении задач проекта. Эти системы создают структуру работ и расписание задач. Менеджеры проектов могут повторно использовать расписания и оценки предыдущих проектов для создания плана текущего проекта. Процедуры (то есть «знание как») требующиеся для реализации проекта, документируются как задачи. Знания, заложенные в план проекта, передаются проектной группе для взаимодействия ее участников и координации выполнения будущих задач.

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

SWOT-анализ применяется для оценки сильных и слабых сторон проекта, потенциальных возможностей и угроз. Эта классическая методика позволяет выявлять и оценивать основные характеристики программного проекта. Группа разрабатывает идеи и рекомендации, специфические для контекста проекта (знания категории «почему»).

Шаблоны — это документы (планы проекта, бюджеты или документация), взятые из выполненных ранее проектов. Эти материалы постоянно используются повторно для поддержки согласованности между проектами. Значительная часть времени обычно тратится на создание документации по проекту в виде планов разработки, контроля качества и тестирования, а также спецификаций требований и архитектуры. Обмен шаблонами с коллегами поможет менеджерам программных проектов использовать практические знания, накопленные при реализации прошлых проектов. Планы проектов или документы с описанием требований, принятые в качестве образца, могут часто повторно использоваться, их адаптируют к требованиям текущих проектов.

Вот нашел интересный доклад.

Авторы доклада

"Анализ социальных сетей в распределенных командах разработки"
Аннаков Байрам, Шатилов Максим
EPAM Systems, ГУ ВШЭ

адрес где можно скачать:

http://www.secr.ru/?pageid=4548&submissionid=4512

В настоящее время все больше и больше команд разработки программного обеспечения являются распределенными. Географическая распределенность таких команд сказывается на взаимоотношениях между участниками, затрудняет коммуникацию и передачу знаний. Анализ социальных сетей позволяет продиагностировать взаимоотношения группы людей, выявить узкие места в коммуникациях и предложить ряд мероприятий для улучшения взаимодействия.
В первой части доклада будет дано определение социальным сетям и описаны подходы к их анализу. Будет введена классификация участников социальной сети и их характеристика.
Во второй части доклада будет описана методология анализа социальной сети, этапы проекта анализа и инструменты для проведения анализа (анкеты, системы анализа почтовых сообщений, программы визуализации результатов анализа).
В заключение доклада будут представлены результаты анализа социальной сети проекта разработки программного обеспечения. Сформулированы основные выводы, представлены диаграммы социальной сети, анкеты и мероприятия, запланированные и проведенные для улучшения взаимодействия участников проектной команды.

Подробности тут http://www.telelogic.ru/company/events/index.cfm?showdetail=y&id=2488&eventtype=Seminar

Обзор

Оперативность в предоставлении новых услуг, создании промышленных и программных продуктов для конечных пользователей является функцией, критичной для любой компании и организации. Необходимость соответствия постоянно меняющимся нормативным актам и внутренним регламентам, разработка в условиях территориально распределенной команды, использование аутсорсинга – все это только усложняет проблему. Ее решение - в применении гибких и быстрых методов разработки, в основе которых лежит правильная и эффективная работа с требованиями. Эта работа дает уверенность, что создаваемые в ходе проекта модели, программные модули, тесты, документация и другие объекты развиваются в соответствии с потребностями пользователей и бизнес-требованиями, которые в свою очередь не статичны, а могут активно меняться в ходе проекта. Решение, предлагаемое компанией Telelogic - Requirements-Driven Development, обеспечивает:

• четкое определение рамок проекта и планирование выпуска версий и релизов продукта

• поддержку процессов управления изменениями, отслеживание дефектов и обеспечение качества в масштабах всего предприятия

• гибкость и поддержку процесса управления требованиями

• мощные средства управления и трассируемости требований на всех уровнях и этапах жизненого цикла производства продукта

• мониторинг производительности и контроль качества в рамках всего проекта.

Ключевые темы

Telelogic Requirements-Driven Development – это Ваш путь к инновациям, путь к достижению конкурентных преимуществ.

На семинаре компании будут затронуты следующие темы:

• управление изменениями на предприятии и конфигурационное управление в рамках жизненного цикла проекта по разработке программного обеспечения

• как перенести опыт управления жизненным циклом приложений на управление разработкой продуктов и услуг

• как обеспечить гибкую, управляемую требованиями поддержку всех процессов проекта

• демонстрация продуктов и решений компании Telelogic.

Нашел материалы курса "Введение в программную инженерию"

автор Карпенко Сергей Николаевич
адрес для ознакомления: http://www.software.unn.ru/?doc=544

По каким признакам выбрать методологию разработки ПО?

Какая методология для каких проектов оптимальна или более всего подходит?

Хочется внедрить RUP , но очень уж тяжеловесная методология.

Остановили пока на ITIL.

Условия: Завод.Около 800 сотрудников.Примерно 100 - ИТР.