Машиностроение и Минтяжмаш
Что такое машиностроение – это как раз понятно – оно занимается производством машин и оборудования, различного рода механизмов для материального производства, науки, культуры, сферы услуг.
Экскурс в экономику 1946- 1985гг
Придется немного отступить назад.
Компания «Техническая документация»
Основные виды деятельности компании «Техническая документация»- разработка технической документации на изделия, программные изделия и автоматизированные системы согласно ГОСТ 2, ГОСТ 7, ГОСТ 19, ГОСТ 24 и ГОСТ 34.
Авторы декларируют на своем сайте, что им удалось автоматизировать разработку технической документации с применением специализированных программных средств на основе «единого исходника (single source)», позволяющих «собирать» документы путем многократного повторного использования структурных единиц — разделов, подразделов, пунктов, подпунктов и т.д. Компания «Техническая документация» проводит исследования: в области стандартизации; автоматизации разработки технической документации; интеграции; а также разработки в указанных областях.
Статьи, опубликованные на сайте, показались мне очень любопытными – они могут оказаться весьма полезными (в том числе довольно большой свод терминов ), при этом стиль изложения не заставляет читателя уходить в сон на 3 или 5 минуте чтения. Мне понравились разделы «Что такое…?» и «Как писать?…»
Коллеги: Сергей Архипенков
UD 2019: Сейчас ссылки на блог Сергея Архипенкова на этом блоге нет — она оказалась битая. Но этот пост со ссылкой на проект «Гуру на Урале» оставляю.
***
Конечно, сегодня, Сергей руководитель проектов и признанный гуру именно в этой области. А сейчас и вообще руководит программой по совершенствованию технологий разработки ПО.
Но на мой взгляд, хороший руководитель проекта, уже по определению Аналитик – а как иначе? И многие статьи и выступления С.Архипенкова в области управления проектами – это очень полезные знания для аналитиков. По крайней мере, я читаю с больши интересом.
А как впечатляет начало пути: 1978 –1997гг: Центр управления полетами, ЦУП (г. Королев)!
В ноябре Сергей провел несколько открытых лекций в Екатеринбурге в рамках проекта «Гуру на Урале». На первой лекции на примере собирательного персонажа Васи Пупкина преподаватель рассказал, каким должен быть программист как часть команды. Что нужно сделать, чтобы стать эффективным членом команды, из чего она складывается, эта эффективность.
Во время второй лекции преподаватель затронул некоторые проблемы разработки ПО. В частности, отсутствие проработанной и подтвержденной теории и визуального представления продукта. Это позволило сравнить разработку с алхимией:). В итоге был дан способ оценки «успешности» проекта.
Директор информационной службы — ссылка и обзор
Раздел ссылок «Периодика» я начинаю с журнала «ДИРЕКТОР ИНФОРМАЦИОННОЙ СЛУЖБЫ».
Почему? Во-первых, это издание «родилось и выросло» буквально на моих глазах. Во-вторых, если продолжать уже начатую тему – разработчик ИТ систем и пользователь, то именно это издание (в отличие от многих современных, предназначенных для разработчиков) публикует много материалов, позволяющих взглянуть на проблемы автоматизации глазами пользователей, являясь при этом журналом, говорящим на «ИТ языке».
Варианты использования вариантов использования
Григорий Грин, декабрь 2009
Статья размещена на блоге автора.
Каждый проектировщик информационных систем рано или поздно сталкивается с вариантами использования (ВИ, англ. — use cases). Но в результате часто случается так, что эта полезная техника используется не по назначению и не приносит ожидаемой пользы. В чём же дело, и как писать варианты использования эффективно?
Алистэр Коуберн [1] еще пять лет назад всё сказал в своей статье «Варинаты использования, десять лет спустя» [2]. Я же здесь попытаюсь лишь добавить несколько практических аспектов из своего личного опыта. Я исхожу из того, что читатель знаком с ВИ (если нет – рекомендую книгу того же Алистэра Коуберна «Writing Effective Use Cases» [3]).
Разные разные пользователи (продолжение)
А теперь на дворе год 2003
Меня пригласили на уже начатый проект. Пользователи – финансовая организация довольно высокого уровня (отвечает за бюджет области).
Этап разработки технического задания завершен, денежки все получены и естественно потрачены. Идет стадия разработки, и уже пришло время эту разработку закончить и сдать. И уже десант разработчиков и аналитиков высадили прямо в офис Заказчика (благо все происходит в одном городе). Ан до выхода на руководство для сдачи Системы и подписания актов дело никак не доходит.
Начинаю разбираться. И вот какие характеристики этого проекта:
- Проект выполняют внешние разработчики.
- Разработка заказная – и с точки зрения пользователя, и для разработчика.
- Система должна была быть разработана для всей организации, но под конкретную функцию. Причем в реализации этой функции участвуют как значительная часть работников собственно финансовой организации, так и сотрудники других организаций (на отдельных этапах) и их много.
- Инициатором разработки АС являлись сотрудники отдела АСУ финансовой организации.
- В этой организации на тот момент разве что курьеры и уборщицы не сидели за компьютерами – а так все были охвачены. Использовалось несколько разных информационных систем, и очень активно задействованы возможности MS Office.
Достаточно гибкости?
Григорий Грин, декабрь 2009
Статья размещена на блоге автора.
Мы являемся свидетелями большой шумихи вокруг гибких процессов разработки (Agile Software Development, [1]). Термин, введённый разработчиками, распространился в мире ПО и за его пределами и используется часто не по назначению. Сегодня все «агильные», а быть «неагильным» просто стыдно. Сам будучи разработчиком пару лет назад, я зачитывался книгами Кента Бека [2] и Мартина Фоулера [3]. Книги замечательные. Эти люди создали очень эффективные методологии разработки ПО. Со смещением моего фокуса в сторону управления проектами, я научился видеть методологии разработки в бизнес-контексте и, в том числе, видеть границы применимости гибких методик. Некоторыми мыслями я хочу поделиться с этой статье.
Начальные условия
Для дальшейших рассуждений важно знать, из каких начальных условий я исхожу. В другой среде могут действовать совсем иные законы.
В нашей фирме несколько десятков программистов. Мы занимаемся индивидуальной разработкой преимущественно веб-приложений с использованием новейших технологий. В каждый момент времени у нас пара десятков актуальных проектов на разных стадиях цикла разработки. За все время существования фирмы были завершены сотни проектов. Наш типичный проект длится 3-6 месяцев, в команде 3-6 человек. Практически все контракты имеют фиксированную стоимость.
Принципы гибких методологий
Давайте взглянем на некоторые принципы гибкой разработки, сформулированные в агильном манифесте [4, 5]:
«Нашим главным приоритетом является удовлетворение заказчика посредством ранней и непрерывной поставки работоспособного программного обеспечения.»
Быть может прямо здесь и зарыта собака? Главным приоритетом является удовлетворение заказчика. Звучит логично, но кто этот заказчик?
Разные разные пользователи
Итак, в добавление к условиям, которые необходимо учесть, начиная выстраивать свои отношения с пользователем АС, первым среди которых, напомню, является: «Являемся мы внешним разработчиком или работаем в качестве ИТ специалистов в той же кампании», есть (а вернее был, когда мне пришлось работать) еще и такой:
— Система, которую мы начинаем делать, придет к пользователям, уже сидящим за компьютерами (то есть это увеличение функций – расширение, замена чего-то – улучшение), или это первая встреча пользователей (и в широком и в узком смысле) с компьютерами.
Еще раз к вопросу о термине «Пользователь». Конечно, как почти любое слово в русском языке, этот термин многозначен. Использовав его в качестве замены более общепринятого в среде ИТ специалистов термина «Заказчик», я хотела подчеркнуть более важные для аналитика аспекты отношений и применила понятие Пользователь «в широком смысле» (или с большой буквы). То есть имея ввиду всю организацию, которая будет применять нашу будущую разработку. Если конкретных людей, использующих систему (программный продукт) много, я их пока – условно – буду называть «конечными пользователями».
Хотя в пору АРМов эти понятия совпадали.
А мой сегодняшний рассказ начинается как раз в эту пору.
Ссылка: АП КИТ
Одна из главных черт аналитика – широта взгляда на все, что связано с профессией. Поэтому очень желательно иметь хотя бы самое общее представление о том, что делается в сфере ИТ в целом в стране – что делают крупные компании-монстры, какова позиция государства, как идет развитие ИТ-рынка, каковы тенденции в развитии законодательства, влияющего на ситуацию в сфере ИТ, и в частности в сфере стандартизации. Сейчас есть возможность мониторить все эти вопросы, просматривая всего несколько сайтов в сети.
Например, сайт АП КИТ (некоммерческой Ассоциации Предприятий Компьютерных и Информационных Технологий).
Мастерская бизнес-анализа 