Архив блога

среда, 2 ноября 2011 г.

Лекция "Современна Программная инженерия . Системная инженерия"

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

Лекция получилась затянутой, наверно про DEMO как и планировал говорит не нужно было, добавил в слайды ссылку на книжку по DEMO (подробней читаем тут: http://techinvestlab.ru/files/504456/demo_praxos_1.doc или в оригинале Jan L. G. Dietz (русск.: Дитц). Enterprise Ontology: Theory and Methodology. -- B., Heidelberg, N. Y.: Springer, 2006 ISBN-10 3-540-29169-5) ).

Слайды, источник многих сладов с конференции RuSEC 2010 http://ru.rise-russia.org/rusec2010

http://www.slideshare.net/Marcus.Akoev/ss-9995330

Если захотите скачать бесплатно зарегистрируйтесь на slideshare.

Звук 142 Мб (двух канальный, жать не буду, через месяц удалю), тут:

https://www.rapidshare.com/files/2631795024/111101_001.mp3

пятница, 23 сентября 2011 г.

Курс Архитектура вычислительных систем

Дисциплина: "Архитектура вычислительных систем" (поток техников СП-643/644)

Один семестр:
7 семестр
14 часов, зачет

Преподаватель: Акоев Марк Анатольевич
Телефон кафедры ПСС: 375-97-18

Адрес сайта с материалами по курсу:
http://akoev.blogspot.com/search/label/Computing

Занятия
Тема
1
Тема 1. Системная/Программная инженерия ACM/IEEE/INCOSE. ISO 15288/12207. SPEM/ISO 24744
2
Тема 2. Документ: от печати до выписок из базы данных. От аппликативного программирования к функциональному.
3-4
Тема 3. Масштабирование от клиента к серверу. От РМД к хранилищам и от хранилищ к semantic web. ISO 15926
5
Тема 4. Описание систем. Системы от железа+ПО к человеку DEMO. От концептуальных диаграмм причин к моделям системной динамики.
6
Тема 5. Индустрия ПО от замысла к производству. От управления проектом к экономике производства систем.
7
Тема 6. От программиста к профессионалу. Прагматичный программист.


Литература
Отдельно к каждой теме
Звук после лекции и скрины доски, может быть будут :)

среда, 31 августа 2011 г.

Пермакультура

В последнем читанном эксперте, опубликована статья: Интеллектуальное земледелие http://expert.ru/expert/2011/33/ntellektualnoe-zemledelie/
Впечатления: грядки выше чем у Митлайдера :)

Очень сильно похоже на реализацию стенаний по старому сельскому хозяйству описанному в книге Благими намерениями государства

Основной тезис против пермакультуры, это не масштабируемость технологии, нужно слишком много людей уровня автора метода. Вчера в разговоре словил мысль, что применение информационных технологий позволит масштабировать технологию. Иначе сложно будет помнить где сыпать горох чтобы свиньи рыхлили нужные участки, а не жрали корнеподы :) Но для массового внедрения ИТ в пермакультуру нужно дождаться, когда минсельхоз США вбухает в технологию сравнимые суммы с теми которые они вбухали в 1930-х в промышленное с/х

Благими намерениями государства

Замечательная книга:
Скотт, Джеймс. Благими намерениями государства. Почему и как проваливались проекты улучшения условий человеческой жизни / Джеймс Скотт; пер. с англ. Э. Н. Гусинского, Ю. И. Турчаниновой. - М. : Университетская книга, 2005. - VIII, 566, [2] с. : карты. ISBN 5-98699-016-1

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

Очень интересна мысль, что все управление основано на классификации. Чем успешней классификация отражает многообразие объекта управления в его среде, тем точнее управление. В принципе книгу можно считать набором иллюстраций к книге Бир, Стаффорд. Мозг фирмы / С. Бир ; пер. с англ. М. М. Лопухина. - Изд. 2-е, стер. - Москва: Едиториал УРСС, 2005. - 416 с.: ил.; 21 см. - Библиогр.: с. 408-414. - Пер. изд.: Brain of the firm / S. Beer. - 2nd ed. - 1981. - ISBN 5-354-01065-9.

Избранный набор цитат ниже.

Профилактику настоящих болезней и инфекций Ленин брал на себя, чтобы быть уверенным, что Кремль - чистая, свободная от микробов среда. Он даже сам писал санитарные инструкции, требуя например, чтобы "все прибывающие (поездом) перед тем, как войти в помещение, принимали ванну и дезинфицировали свою одежду ..., любой, отказывающийся повиноваться санитарным инструкциям, будет удален из Кремля сразу за
попытку причинить социальный вред".
Благими намерениями государства, 2005. стр 280 сноска 22

То технологии мобилизационной экономике мы обязаны Вальтеру Ратенау, с его технологией планирования снабжения войск. Цитата:
"Мировая война [WWI] была высшей точкой политического влияния инженеров и плановиков. Увидев, что произошло в чрезвычайных обстоятельствах, они представили себе, что было бы, если бы такая энергия и такое планирование были направлены на народное благосостояние, а не массовое разрушение. (стр. 165)

Также интересно, что эргономические исследования организации производства выполнял параллельно с Тейлором и институт физиология труда кайзера Вильгельма (Kaiser-Wilhelm Institut für Arbeitsphysiologie)

Возможно более точная цитата:
«Русский человек – плохой работник по сравнению с передовыми нациями. И это не могло быть иначе при режиме царизма и живости остатков крепостного права. Учиться работать –эту задачу Советская власть должна поставить перед народом во всём её объёме. Последнее слово капитализма в этом отношении, система Тейлора, -как и все прогрессы капитализма, - соединяет в себе утончённое зверство буржуазной
эксплуатации и ряд богатейших научных завоеваний…<…> Советская республика во что бы то ни стало должна перенять всё ценное из завоеваний науки и техники в этой области. <…>Надо создать в России изучение и преподавание системы Тейлора, систематическое испытание и приспособление её. Надо <…>чтоб были заложены основы социалистической организации соревнования, а с другой стороны, требуют применения принуждения…»
В. И. Ленин «Очередные задачи советской власти» (раздел «Повышение производительности труда») ПСС, т.36

Главным проводником в 1920-х в СССР тейлоризма был: Алексей Капитонович Гастев.

"Большинство трудовых институтов было закрыто, а их эксперты высланы или застрелены во время сталинских чисток 30-х годов" (стр 174-175, прим 48)




суббота, 27 августа 2011 г.

Обсуждения процесса разработки ПО

Обсуждать процессы разработки ПО лучше с использованием моделей (как это делать читаем в книге рецензия на которую тут http://expert.ru/ural/2011/26/dostich-gorizonta/)

Как читать и строить модели читаем тут
http://expert.ru/ural/2011/26/i-zaglyanut-za-gorizont/

Готовые модели для SoftEng берем тут
Software Process Dynamics
Publisher: John Wiley & Sons    Publication: 2008, English    ISBN: 9780471274551    Pages: 601

Используем инструмент Vensim http://www.vensim.com/download.html
версия PLE для академического использования достаточна для того чтобы построить и поиграть с большинством моделей.

Методы оценки приведены в:

Макконнелл, Стив. Сколько стоит программный проект: [пер. с англ.] /
С. Макконнелл. - Москва ; Санкт-Петербург ; Нижний Новгород [и др.]:
Русская Редакция : Питер, 2007. - 297 с.: ил.; 23 см. - (Библиотека
программиста). - Библиогр. в конце гл., библиогр.: с. 286-293. - Алф.
указ.: с. 295-296. Пер. изд.: Software Estimation: Demystifying the
Black Art / Steve McConnell. - ISBN 978-5-7502-0295-9.


Мараско, Джо. IT-проекты: фронтовые очерки: эссе об упр. успешными
проектами / Джо Мараско ; [пер. с англ. С. Маккавеева]. -
Санкт-Петербург ; Москва: Символ-Плюс, 2008. - 384 с.: ил.; 22 см. -
(Профессионально). - Библиогр. в примеч. - Алф. указ.: с. 371-378. -
Пер. изд.: The Software Development Edge / J. Marasco. 2005. - ISBN
978-5-93286-096-0.

Отличный обзор работ в которых приводятся результаты экспериментальных исследований процесса разработки ПО

Роберт Гласс
Факты и заблуждения профессионального программирования
Facts and Fallacies of Software Engineering
Издательство: Символ-Плюс, 2007 г. , 240 стр.

четверг, 11 августа 2011 г.

Выбор ПО для прототипирования интерфейса

Критерии выбора ПО для прототипирования интерфейса должны быть следующими:
  • описание прототипа в формате, допускающем двухсторонний обмен.
    • То есть нужно уметь по построенному прототипу сделать заготовку форм для рабочего проекта, чтобы не заставлять программиста создавать код интерфейса с нуля.
    • И нужно уметь сгенерить заготовку интерфейса по существующим формам для их доработки или использования в качестве шаблонов.
  • формат описания интерфейса должен быть достаточно высокоуровневым, чтобы можно было ссылаться на существующие компоненты.
  • движок должен поддерживать схему переходов между формами. Два режима важны:
    • кликабельные области с вызовом форм, на которые переходим.
    • диаграмма перехода между формами, причем диаграмма должна должна однозначно соответствовать кликабельным областям, то есть если добавили кликабельную область со ссылкой на форме, то соответствующая связь должна быть добавлена на диаграмме переходов между формами.
    • дополнительно тулза должна умепть поддерживать фолдинг или более предпочтительно подобласти, чтобы диаграммы были читабельными. Плюс диаграммы желательно уметь экспортить в обменные форматы, чтобы их можно было использовать без ПО в которой они созданы.
  • должен быть режим обсуждения и правок и замечаниями. Идеал интеграция с существующими средствами issue tracker.
  • желательно должна поддерживаться возможность версионирования и инструмент сравнения версий (идеал графический инструмент diff для форм и диаграмм).
  • обязательно должна быть возможность к компонентам интерфейса привязывать полуструктурированные записи, идеал часть информации должна браться из описания информационной системы, например поля и сущности схемы базы данных, форматы вывода и прочее.
Что хочется иметь по результатам использования тулзы:
  • быстро накидать интерфейсную форму, которую можно обсуждать
  • по прототипу построить:
    • задачу на создание интерфейсной формы с указанием, откуда берутся и как выводятся данные (см последний пункт пожеланий про полуструктурированные записи).
    • чеклист для тестировщика, что проверять.
Обзор инструментов быстрого прототипирования
http://habrahabr.ru/blogs/ui_design_and_usability/70001/
Более свежий обзор
http://slodive.com/web-development/wireframe-tools/
От Balsamiq у меня не очень впечатления, в целом хорошо, но в использовании противен (чисто личное не приятие).
http://balsamiq.com/support/documentation
Serena Prototype Composer - больше понравился, тк позволяет сграбить интерфейс с существующего приложения и поразвлекаться. Может больше, тк это полноценная управления проектом, среда сбора требований и порождения из нее задач.
http://www.serena.com/products/prototype-composer/index.html
Pencil - бесплатное решение, пользую его как наименее противный, но какой он тормозной при старте :( это что то.
http://www.evolus.vn/Pencil
Вариант http://wireframesketcher.com мне кажется пока предпочтительным, есть схема перехода между формами и выгрузка в человечий формат. Стоит денег, но не много. Является расширением http://www.eclipse.org/ . Нужно проверить на возможность создания расширений графической библиотеки.

пятница, 5 августа 2011 г.

Профессиональные организации в области программирования

Рано или поздно разработчик достигает предела развития в компании, ему некуда расти, возникает дилемма свалить или смирится. но "свет с запада" дарует нам третий путь присоединения к сообществу профессионалов.

Что это дает:
1. возможность читать периодику с архивом которую выпускают сообщества, за членский взнос, который часто меньше чем стоимость годового комплекта журнала. В сторону библиотек показывать не стоит, в УрФУ есть подписка только на журналы одного общества, универов в стране где есть такая же или большая подписка еще два или три :(
Если есть сомнение стоит ли читать сложные тексты, стоит задуматься о тщете всего сущего :(

2. возможность участвовать в обсуждении в группах (часто очных) профессиональных проблем.

3. доступ к курсам, сертификации и пр. Сертификация профессиональная, а не коммерческих фирм.

4. На западе участие в группах дает еще возможности быть привлеченным в интересный проект, тк сообщества это и экспертные группы по подбору профессионалов, обратная сторона если ошибся, то сообщество гарантирует, что в серьезных проектах участвовать не будешь (этакий аппарат ЦК КПСС ;)

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

Важное условие, практически вся информация на анг языке.

Список сообществ которые могут быть интересны:


IEEE Computer Society (IEEE CS)
http://www.computer.org/
В России действует несколько отделений головной организации IEEE, но они скорее по части электриков и радистов. Кузнецов Сергей Дмитриевич регулярно призывает вступать в Российское отделение (http://citforum.parma.ru/computer/) и печатает обзоры публикаций в Открытых системах http://osp.ru
Учитывая сумму взноса стоит подумать о вступлении, но библиотека http://ieeexplore.ieee.org/ того стоят.
стоимость порядка $300 в год.

ACM
ACM (Association for Computing Machinery) является крупнейшей всемирной научной и образовательной организацией, объединяющей более 75000 профессионалов компьютерной науки. Основанная в 1947 г, АСМ ежегодно проводит до 100 международных (научных и практических) конференций, издает несколько десятков научных журналов и присуждает большое количество авторитетных наград за достижения в области компьютерной науки, в т.ч. A.M. Turing Award, известную как "нобелевская премия информатики".
Деятельность ACM проходит в "группах по интересам" - Special Interest Group, всего таких групп около сорока. В России действует две национальные группы SIGMOD (базы данных) и SIGCHI (человеко-машинное взаимодействие).
Под эгидой ACM проводятся ежегодные международные студенческие олимпиады по программированию.
Подробнее об ACM можно прочесть на Internet-сайте ассоциации: http://www.acm.org/.
Стоимость порядка $150 в год.

INCOSE
Международное сообщество системных инженеров. В России очень живы и деятельны. Почему приведены среди программистских сообществ? На то две причины:
1. Программная и системная инженерия сливаются, вплоть до того, что проект стандарт образования Soft/SysEng общий и готовят его три перечисленных организаций.
2. Иногда стоит смотреть что происходит в железе и замыкаться миром программирования.
Сайт http://incose.ru/
Очные встречи вторую и четвертую среду месяца в Москве (для иногородних организуется видеотрансляция).
Материалы заседаний: http://community.livejournal.com/incose_ru 32 заседания (доступен архив 15 видеозаписей)
Участвуют только члены INCOSE (вступить стоит $105 вот тут: http://incose.org).

вторник, 28 июня 2011 г.

Литература по тестированию

Не притязая на полноту, перечисляю что нашел дома, на полке (не факт, что я их читал *^_^* ).

Сразу дам ссылку на форум где книги обсуждались, если кому интересно зарегтесь, может дадут скачать :)

http://software-testing.ru/forum/forum/78/


  1. Сэм Канер, Джек Фолк, Енг Кек Нгуен
    Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений
    http://software-testing.ru/forum/topic/13031/
    Считается библией тестирования
  2. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах
    http://software-testing.ru/forum/topic/8133/
    а это катехизисо :)
  3. Роберт Калбертсон, Крис Браун, Гэри Кобб. Быстрое тестирование
    http://software-testing.ru/forum/topic/2167/
  4. Блэк Р. Ключевые процессы тестирования  http://software-testing.ru/forum/topic/13030/
  5. Винниченко И.В. Автоматизация процессов тестирования
    http://software-testing.ru/forum/topic/13032/
    не скажу что в восторге от книги

Слабо полезные книги?
  1. "Автоматизированное тестирование программного обеспечения"
    Элфрид Дастин, Джефф Рэшка, Джон Пол http://software-testing.ru/forum/topic/7757/

Дополнение про процесс: само тестирование в отрыве от контекста организации процесса разработки занятие с сомнительной полезностью. При тестировании важны следующие аспекты:
1. Приоритеты, сперва тестируются ключевые механизмы потом рющечки. Тк тестировщик не должен обладать всеведением, но благость ему не помещаем :), аналитик/разработчик явно должен сообщать что тестировать в каком порядке. (Почему так прочтите книжку по ТОС или о бережливой разработке ПО) Вопрос на пять рублей с помощью какого механизма? (ответ приоритетов)
2. Исправление ошибок, если ошибки висят долго не исправленными мораль тестировщика падает ниже критического уровня. Если компания не готова исправлять все ошибки.. читай Джоэля, что потом бывает :( на самом деле ничего плохого :)
3. Что нужно тестировать. Вопрос интересный и на него ответит нам регламент тестирования, хотя бы частично. Но формально, тестируют то что написано в задаче (если она есть), что подразумевается, фантазию пользователя и пользовательскую документацию...
4. Про Unit тесты и автоматизацию упомянуть стоит, но для их воплощения нужно приложить усилия. К сожалению усилия сейчас, а результат потом.
5. Воспитательный аспект. Если тестировщик не "несет возмездие во имя луны"* :) то элементы цепи до него будут считать себя локальными центрами вселенной. Я конечно не призываю носить черную одежу и после каждой найденой ошибки являться к программисту и указав на ошибку гнусно хихикать (реальный случай, самая эффективная группа тестирования, к сожалению склероз выкосил знания о месте и времени)

Вывод: Сколько книг ни читай, а императором не станешь. Мао Цзедун **

* я не являюсь поклонником Луны в тельняшке и махо седзе
** достоверность цитаты сомнительна, в Красной книжке ее нет. Проверять в домене .cn нет желания.

понедельник, 20 июня 2011 г.

Миф о документации

Gaperton разразился текстами про документацию, к сожалению текст не 
везде цензурный, но по делу 

лучше читать сразу продолжение
http://gaperton.livejournal.com/60632.html

исходный пост тут
http://gaperton.livejournal.com/60277.html

Кто не сочтет возможным для себя читать не гладко выраженные мысли, 
краткое резюме:
в документации есть две стороны писатель и читатель (тема читателя до 
конца не раскрыта  )

есть три типа программистской документации:
1) "Договор". - для это ТЗ или задачи в трекере
2) "Справочник". - то что с трудом пытаемся писать в wiki и код, но для 
кода нужен ключ доступа новым читателям.
3) Обучающий материал. - то что нужно создать, но стоит очень дорого
 
Для ключей к справочникам нужны:
1. номера ревизий закрывающие задачи (чего не всегда делается)
2. коменты по задачам, удаляя срач мы удаляем часто единственные зацепки 
которые позволят понять устройство системы

Отсебятина к тексту, дополнительно нужны:
3. описание архитектуры, как ее состыковать с кодом хз
4. документы по прохождению развилок, хз как писать
5. модель для проверки консистентности постановок, хз как ее реализовать

все выше написанное не отрицает того, что документация важна и нужна 

среда, 6 апреля 2011 г.

Софт для разработки пользовательских историй при разработке персонажей

При разработке UI один из методов составление пользовательских историй, 
с формированием персонажей. Близкую задачу решают авторы сценариев, для 
которых разработано несколько продуктов, один из которых бесплатен.

Celtx
http://www.celtx.com/index.html

Не очень полное описание:
http://text-process.blogspot.com/2008/12/celtx.html
 
Еще б оно было интегрировано с инструментом UI прототипирования, цены бы не было.
 

Как выглядит IT поддержка учебного процесса в небольшом английском вузе

Подход к образованию по-английски
http://habrahabr.ru/blogs/study/90509/

Сдача сессии по-английски
http://habrahabr.ru/blogs/study/80732/

четверг, 17 марта 2011 г.

Блоги про e-learning

http://elearningtime.blogspot.com/
упор на примеры, скорее создан для рекламы своей деятельности. Мне 
кажется интересным тк публикует учебные материалы по использованию 
средств -learning

http://lern21.livejournal.com/
дневник мыслей вокруг образования и ПО разработчика трехмерных 
образовательных сред, блог сделан анонимным чтобы не вести рекламу 
разрабатываемых продуктов.
часто публикует концептуальные материалы, из последних цикл про "Главные 
принципы обучения Дэвида Мэрилла"

пример что нужно ППС от Sakai и подобных проектов

пример что нужно ППС от Sakai и подобных проектов

http://blog.evernote.com/ru/2011/01/18/10-tips-for-teachers-using-evernote-education-series/