61

Системный Анализ и Требования / Re: РД 50-34.698-90. Стадия "Формирование требований к АС". Отчет.

« : 21 Июля 2008, 11:26:47 »

Спасибо.
Тогда такой вопрос.

Какой документ разрабатывается на выходе предпроектного обследования? Proposal? А если Заказчик - ГосУчреждение (с требованием писать документы по ГОСТу)?

Скорее всего, наиболее приемлемым документом для Заказчика будет ТЗ. После того, как Вы его согласуете с Заказчиком, его можно будет включить приложением к договору с Заказчиком (с обязательством Исполнителя реализовать систему в соответствии с ТЗ). Тем самым требования по каждому пункту ТЗ станут юридически значимыми.
Нужно только учесть, что ГОСТ ориентирован на функциональное представление системы. А значительная часть приложений сейчас разрабатывается и реализуется в объектно-ориентированном подходе. И если Вы собираетесь использовать описание ВИ (use cases) для описания требований в ТЗ по ГОСТ, то местами в тексте ТЗ Вам придется достаточно "творчески" отображать объектно-ориентированные представления в функциональные , имея в виду, что ВИ - не тождественен функции.

62

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 18:10:41 »

А №1 - такое вообще бывает???

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

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

63

Системный Анализ и Требования / Re: Преимущества выстроенного процесса Управления Требованиями

« : 10 Июня 2008, 17:02:05 »

ИМХО стоит артикулированно отделить две ситуации:
1. Требования Заказчика ясны как пять копеек, а управление требованиями - возможность организации гибкого, но управляемого процесса разработки. По идее такое может потребоваться если компания пробует внедрять новую технологию разработки, что создает дополнительные риски управления проектом (в части понимания в любой момент что именно зачем делаем).
2. Заказчик сам не знает точно, что хочет (редкий Заказчик готов предъявить более-менее ИСЧЕРПЫВАЮЩИЙ список своих ключевых/целевых показателей). Тогда управление требованиями - способ поворачивать разработку вслед за полетом мысли Заказчика уже в процессе разработки, а также возможность оперативно предъявлять ему требования по пересмотру сроков и оценку увеличения стоимости разработки, буде он такие виражи будет закладывать . Для Заказчика пропагандируется гибкость разработки ("раз уж Вы сейчас не можете точно сформулировать требования..."). Для начальника - снижение рисков взять на себя невыполнимые обязательства по договору, возможность раннего выявления скрытых противоречий в требованиях Заказчика.

64

Варианты Использования (Use Case) / Re: Розенберг против Коберна

« : 25 Марта 2008, 23:40:40 »

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

65

Варианты Использования (Use Case) / Re: Розенберг против Коберна

« : 25 Марта 2008, 15:32:21 »

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

66

xP Xd Agile ICONIX пр. / Re: Agile CMMI или скоро все будет Agile?!

« : 21 Марта 2008, 13:59:19 »

Ох, по-моему такие аналогии очень редко хорошо работают.

Аналогии могут быть многоаспектными, я ведь прямо указал на тот аспект деятельности (целеполагание и управление достижением цели) применительно к которым интересно было бы проследить сходство и различие проблем в сравниваемых областях. Т.е. если уж говорить о том, как аналогии должны "работать" то ИМХО представляет смысл рассматривать схожие проблемы в отдельных практиках, и смотреть какие решения применялись для этих проблем. Может быть и для проблемы аналогичной практики найдется решение. По аналогии .
А обосновывать преимущества капитализма и теории товарно-денежных отношений в качестве методологии управления проектами (и семейными отношениями ) в противопоставлении Agile я совсем не собирался. Более того, с большой симпатией и уважением отношусь к Вашей подвижнической деятельности на ниве Agile и желаю Вам всяческих успехов . Но тему границ возможности успешного применения Agile  полагаю важной для успешного применения практики Agile как таковой, а также для дальнейшего развития ИТ-методологий. В том числе путем создания разнообразных "гибридных" практик, что и было исходной темой данного обсуждения.

67

xP Xd Agile ICONIX пр. / Re: Agile CMMI или скоро все будет Agile?!

« : 20 Марта 2008, 14:44:55 »

Практики Agile вызывают ассоциации с различными формами реализации коммунистических идей начиная с 19 века (причем именно не сталинской модели, а модели коммуны). Тот же акцент на специфические формы коммуникации/обсуждения/принятия решений как ключ к успешному/эффективному результату. А также специфические же формы коллективной организации работ. Поэтому можно ожидать, что в ближайшее время должно проявиться понимание плюсов и минусов Agile, которые были характерны и для "коммунарских" форм организации. В первую очередь - применительно к проблемам целеполагания и управления достижением цели.

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

68

Проектирование / Re: Что такое проектирование и каковы его цели?

« : 29 Февраля 2008, 12:41:54 »

Shur, утро доброе

Пытался ответить вчера, не смог запостить сообщение.

Я согласен, что ГОСТ рекомендует, но не определяет на 100% кто готовит ТЗ.

Вы пишите, что практика такова, что ТЗ все-таки пишет Заказчик и согласует его с Разработчиком.
Хорошо. Тогда раз Заказчиком проекта выступает преподаватель, то он и должен формировать это ТЗ. Более того в лекции он это утверждает как распространенную практику. Отчего же заставляет студента формировать это ТЗ, да еще следит, чтобы оно соответствовало ГОСТ. ИМХО, пусть и готовит ТЗ на каждую курсовую и уже проверяет проект на соответствие ему Однако практика учебных занятий такова, что все делает студент - придумыает себе задачу, пишет ТЗ, пишет проект.
Такое безусловно также имеет место быть в реальной жизни.

Я бы уточнил ГОСТ в том смысле, что написание ТЗ также может производиться по заказу Заказчика. Но заказ на оформление требований (ТЗ) и заказ на проектирование системы в соответствии с ТЗ имеет смысл реализовывать как разные заказы, выполняемые разными исполнителями. Для написания ТЗ больше востребованы услуги бизнес-аналитиков, проектирование конкретных решений по этому ТЗ - скорее работа архитектора (системного аналитика).  Возможно и при обучении в институте имеет смысл на уровне конкретных заданий студентвм артикулированно разделять эти работы. Вплоть до того, что один студент оформляет ТЗ, а другой - проект по этому ТЗ.
Учитывая, что в жизни эти процессы разнесены (т.е. начинать проектировать надо когда ТЗ уже готово), проекты могут делаться по ТЗ, составленными студентами в предыдущие годы.
Неразличение задач формулирования ТЗ (требований) и собственно проектирования приводит в жизни, как правило, к перекосу в сторону насыщения ТЗ детальными требования по реализации системы. Особенно, если ТЗ пишет тот,кто по нему будет делать систему. Спецализация по написанию ТЗ по идее должна быть востребована для ИТ-подразделений компаний, занимающихся скорее эксплуатацией ПО и оборудования и обслуживанием пользоваталей, чем его разработкой. Если на такую работу брать людей, которые мечтают разрабатывать программы, а поддержку существующего ПО воспринимают как каторгу, то при написании ТЗ они пытаются неоправданно акцентировать технические детали проекта, мешая исполнителям-разработчикам. И не всегда качественно выполняют работу по сбору требований от собственной организции. Поэтому. в учебной ситуации ТЗ студент мог бы составлять и по требованиям, которые он должен узнать от преподаваталя, но модель их взаимодействия должна соответствовать ситуации общения косноязычного начальника и его подчиненного IT-ника  .
Говорят, раньше старались не брать в авиационно-технические училища ребят, которые мечтали стать летчиками. Потому что они, иногда, дорвавшись до самолета,  пытались таки осуществить свою мечту....

69

Проектирование / Re: Что такое проектирование и каковы его цели?

« : 28 Февраля 2008, 17:32:39 »

Например в лекция была фраза, что ТЗ разрабатывается заказчиком с участием разработчика (тогда как ГОСТ 34 определяет строго наоборот)

Вообще-то это беда, что в ГОСТе написано... Правда в Приложении к ГОСТ 34.602-89 на ТЗ, где указано, что ТЗ делает разработчик, приписано, что это рекомендуемый порядок. На практике трудно себе представить, чтобы при организации конкурса, участники конкурса каждый сначала независимо донимал Заказчика своими интервью, а потом участники конкурса "мерялись" бы теми ТЗ, что у них получились. ТЗ на конкурс, сейчас, как правило, предлагается уже готовое. А участники конкурса уже делают предложения по реализации требований (типа предпроект или "натягивают" на требование свой набор типовых и уже документированных решений).

По идее
1. сначала формируется представление о системе в целом (Эскизный проект). Начальство очень любит при всяких приемках и утверждениях читать эти документы .
2. потом прорабытваются  детали (пишется задание/ТЗ на их проектирование) из которых собственно система состоит и/или пишется заказ на приобретение готовых (Технический проект).
3. Потом "Рабочую документацию" пишут. В ГОСТ 34 про это сказано, но немного "размазано" - там и на стадии эскизного проекта в п. 4.2 пишут "документацию на АС и её части" и потом то же самое в п.5.2 продолжают на стадии Технического проекта....
Такая схема процесса принята и в зарубежной практике сооружения объектов (у них construction - это не только строительство- building, из камня, но и чисто из металла может быть). Высоко ценятся люди с опытом Front end engineering (FFED)  - это типа нашего этапа ГОСТ "Разработка концепции АС".

Поэтому можно попытаться определить "проект" и "проектирование" не только математически исчерпывающим определением, но и указанием от чего эти понятия стоит отличать. Типа, чем понятийно проектирование отличается от моделирования и конструирования (причем не только в ИТ). Чем рабочая документация отличается от эсксплуатационной.

70

Примеры / Re: Моделирование системы внутреннего контроля

« : 22 Февраля 2008, 12:57:36 »

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

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

71

Примеры / Re: Моделирование системы внутреннего контроля

« : 21 Февраля 2008, 10:21:45 »

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

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

72

Обучение / Re: Манифест: Лучший в России Учебник

« : 20 Февраля 2008, 19:38:00 »

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

Насчет связи менеджмента и инженерного проектирования:
1. В отечественной практике сотрудник проектной организации никакой юрисдикции над рабочими, которые строили по его чертежам дом или самолет, практически не имел. Если он и приобретал практику управления, то в основном управления своими подчиненными внутри проектной организации. Опыта управления рабочими на стройке или производстве он при этом не приобретал. Остановить работы на площадке или в цеху в рамках авторского надзора за нарушение проекта он практически не мог. Для сравнения: один знакомый рассказывал, как несколько лет назад заказали горелки для подогрева перед прокатом на стане металлической заготовки  по немецкому проекту одному отечественному предприятию. Приехал немец в рамках авторского надзора, осмотрел готовые горелки, все забраковал полностью. Пришлось еще несколько сотен баксов платить - заказывали другому предприятию. Я что-то не слышал аналогичных историй из отечественной практики советского времени.... Поэтому инженерное дело в зарубежном варианте предполагает иной уровень ответственности автора проекта за результат. Сама отечественная практика часто не предполагала высокого качества проектирования, многое потом делалось по месту на производстве. В лучшем случае низкая культура производства и ограниченность средств учитывалась при проектировании. При этом детальность объяснений инженера проектировщика фактически переходила в управление технологическим процессом. Это не стимулировало и высокую культуру производства, особенно в гражданском секторе - значительная часть объектов и деталей могла выполняться вообще без чертежей, а только на основании эскизов и устных объяснений проектировщиков.Эта кривизна часто выставлялась чуть ли не как наше ноу-хау...
2. На производстве, чтобы реализовать проект по кривой документации хороший исполнитель, прежде всего линейное руководство, должен был иметь приличную инженерную культуру. Поэтому прораб у нас - это в гораздо большей степени инженер, чем менеджер. И вот у него как раз инжиниринг и менеджмент часто сливаются нераздельно... У зарубежных строителей инженер-проектировщик и прораб отличаются даже цветом касок,когда находятся на площадке (корпоративная норма в рамках компании).
3. Поэтому представляется важным развивать
3.1 практики выработки требований к проекту не только по строгому соответствию неким НСИ но и требованиям конкретного Заказчика, пользователя, реального человека для которого это все это делается.
3.2 иметь возможность проверить, как сделано и иметь право и возможность отказаться санкционировать приемку работы, если она требованиям не соответствует. При этом чтобы не надо было "стоять над душой" у исполнителя, учить и заствлять его выполнять его прямые обязанности, а иметь возможность прийти и проверить сделанную работу. Иметь возможность прописать такое разделение функций в договоре, чтоб Исполнитель потом не мог оправдать собственную беспомощность низким качеством проектирования.
3.3 При этом чтобы Исполнитель мог оценить качество проекта до того, как он обнаружил его кривизну в процессе исполнения.

По любому придется расставаться с практиками, опирающимися на "человека-оркестра"  и готовность переделки работы from the scratch на каждом этапе. Как в ИТ, так и в других сферах.

Если эти практики удастся исправить опираясь на  уже существующие термины и понятия - ну что ж, тем лучше...

73

Обучение / Re: Манифест: Лучший в России Учебник

« : 20 Февраля 2008, 17:01:47 »

Для пункта 1.2 предполагаемого плана книги предлагаю попытаться ввести в обращение термин "инжиниринг" и его IT-аналог software engineering (IT-инжиниринг?). По этой ссылке есть интересная история термина.

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

Использование понятия инжиниринг:
1. Дает возможность вернуть отечественному инженеру обязанность  и возможность руководствоваться требованиями потребителей своего труда при проектировании. Позволяет вооружить его для этого концептуальными средствами и представлениями, опираясь на мировую практику. Ответственность (в широком смысле, а не только в смысле УК) за результаты инженерного труда (внедрение, пусконаладочные работы) также должна быть включена в содержание инженеринговой деятельности (что соответствует тенденциям в мировой практике).
2. Перербросить смысловой "мостик" между IT и "традиционным инжинирингом" в той части, где их деятельность имеет много общего (особо важная задача для России).

74

Примеры / Re: Моделирование системы внутреннего контроля

« : 20 Февраля 2008, 15:54:28 »

Здравствуйте.
Столкнулся с некоторыми проблемами при разработке модели бизнес-процессов, и хотелось бы испросить совета у уважаемой публики....

А в чем сама проблема-то (для Вас лично при разработке модели) ?

75

Нововведения / Re: Процесс обратной семантической трассировки

« : 13 Января 2008, 19:46:05 »

ИМХО попытка ограничиться использованием исключительно UML пока преждевременна. Очевидно, что это сильно сужает выразительные средства участников создания системы (как со стороны Заказчика, так и со стороны разработчиков). А цель? Ускорение (удешевление) разработки? Более точный учет требований в коде? Более точное соответствие формулировки требований реальному смыслу, который в них вкладывает Заказчик?

Скорее аскетизм выразительных средств UML позволяет средствами UML искусственно загрубить конткекст обсуждения участников создания системы, чтобы более рельефно выявить самые важные, глубинные контуры структуры и функционала системы. При этом поясняющие детали, в том числе на "естественном языке" могут добавляться по необходимости. И отбирать у участников разработки такую возможность скорее  контрпродуктивно.

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

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