Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Набрел на одной из тем форума вот на такую схему организации взаимодействия подразделений по разработке ПО /topic/358492&pg=5#3424564 Вопрос оказался достаточно актуальным Однако, вопрос интересен в контексте внедрения одной из ERP систем (модификации) Должен заметить, что ощущается неслаженность работы. ТЗ выдается в разработку, разработка выдает продукт, далее модификация ТЗ, далее опять возврат... Короче говоря очень маленький процент случаев когда запрос клиента проходит прямой путь без возвратов от самого запроса до выдачи готового продукта клиенту. Приведенная схема достаточно интересна. Как указано в сообщении "обсосано сто раз". Однако, лично я не часто наталкивался на информацию подобного рода. Хотелось бы изъявить возможно не только мое желание сбора информации по этой теме и сосредоточение ее в этой теме. Будет это будет полезно не только мне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:20 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterНабрел на одной из тем форума вот на такую схему организации взаимодействия подразделений по разработке ПО /topic/358492&pg=5#3424564 Вопрос оказался достаточно актуальным Однако, вопрос интересен в контексте внедрения одной из ERP систем (модификации) Должен заметить, что ощущается неслаженность работы. ТЗ выдается в разработку, разработка выдает продукт, далее модификация ТЗ, далее опять возврат... Короче говоря очень маленький процент случаев когда запрос клиента проходит прямой путь без возвратов от самого запроса до выдачи готового продукта клиенту. Приведенная схема достаточно интересна. Как указано в сообщении "обсосано сто раз". Однако, лично я не часто наталкивался на информацию подобного рода. Хотелось бы изъявить возможно не только мое желание сбора информации по этой теме и сосредоточение ее в этой теме. Будет это будет полезно не только мне. постараюсь не сильно размазывать мысль по древу....укажу лишь минусы представленного чертёжика... на данном чертёжике видно, что нет ОБРАТНЫХ связей до клиента. и пока крутилось внутри конвеера (программеры-тестировщики-новый функционал) получили вместо "ужа", 100 метров "колючей проволоки". Которая в свою очередь заказчику нафик не нужна... или по другому...при такой архитектуре организации работы - слишком велики риски... удачи Вам (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:28 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
kolobok0на данном чертёжике видно, что нет ОБРАТНЫХ связей до клиента. и пока крутилось внутри конвеера (программеры-тестировщики-новый функционал) получили вместо "ужа", 100 метров "колючей проволоки". Которая в свою очередь заказчику нафик не нужна... или по другому...при такой архитектуре организации работы - слишком велики риски... ++ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:30 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
безусловно обратная связь должна иметь место... хотя ... думаю замечание можно устранить модифицировав связь "Клиент"-"Анализ ТЗ и ошибок" на двухстороннюю однако, считаю, что больше связей "..." - "клиент", кроме существующих существовать не должно ... иначе опять получится карусель с "бегающими лошадками", а еще хуже лабиринт :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:39 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Господа, поактивнее! Думаю эта проблема актуальна для многих компаний мирового уровня (да и не только), в которых поддерживается концепция процессного подхода ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 16:09 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterГоспода, поактивнее! Думаю эта проблема актуальна для многих компаний мирового уровня (да и не только), в которых поддерживается концепция процессного подхода Концепцию надо менять, потому что Проект - это УНИКАЛЬНОЕ предприятие по созданию УНИКАЛЬНОГО продукта. Т.е. ручная работа а не конвейер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 17:40 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
а какое имеет значение какое предприятие - подход-то может быть один в любом случае это работа с клиентом, который выдает запрос и ожидает готовый продукт. А манипуляции внутри проектной группы может быть универсальной ... по прописанной схеме для любого проекта. В любом проекте есть запрос клиента, разработка ТЗ, реализация, выдача результата (ну разумеется это не полный ряд операций). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 17:56 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
на картинке собственно то, что в голову пришло с учетом настроенной схемы у нас, а также с учетом личных размышлений может быть кто что дополнит общими усилиями (с учетом специфики организации схем разных компаний) возможно получится нарисовать универсальную схему, которая уж точно подойдет ну ... по крайней мере ... для жизни в клиенте-холдинге .... хотя уверен, что и не только. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 18:05 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterа какое имеет значение какое предприятие - подход-то может быть один в любом случае это работа с клиентом, который выдает запрос и ожидает готовый продукт. А манипуляции внутри проектной группы может быть универсальной ... по прописанной схеме для любого проекта. В любом проекте есть запрос клиента, разработка ТЗ, реализация, выдача результата (ну разумеется это не полный ряд операций)."Процессный подход" обычно подразумевает использование цикла PDCA (в терминологии TQM и ISO 9000) или цикла DMAIC (в терминологии "шести сигм"), а по-русски, цикла постоянных и мелких улучщений. Именно использование этого цикла предоставляет процессному подходу его основные преимущества. Но он не может использван для процессов, которые задействуются однократно . Для однократных процессов обычно используются другие подходы. А именно, подходы "проектного управления", таргет-костинг, "кайкаку" (из JIT). В "шести сигмах", правда есть какой-то специфический цикл для инновационных процессов DMADV, но я с ним пока не разобрался - не уверен, что его в данной ситуации можно использовать (сейчас изучаю "шесть сигм"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 19:28 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterна картинке собственно то, что в голову пришло с учетом настроенной схемы у нас, а также с учетом личных размышлений может быть кто что дополнит общими усилиями (с учетом специфики организации схем разных компаний) возможно получится нарисовать универсальную схему, которая уж точно подойдет ну ... по крайней мере ... для жизни в клиенте-холдинге .... хотя уверен, что и не только. Схема слишком линейная. Заказчик должен быть вовлечен во все этапы разработки, а не ограничиваться точечным контактом с аналитиком. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 10:06 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Флеймер Схема слишком линейная. Заказчик должен быть вовлечен во все этапы разработки, а не ограничиваться точечным контактом с аналитиком. не совсем согласен ... клиенту по большому счет все-равно что там делается в разработке. Ему важен результат. Он дал запрос и ожидает результата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 12:34 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
А у программистов никогда не возникает вопросов по предоставленному ТЗ? Аналитик может дать исчерпывающий ответ на все вопросы программистов не прибегая к консультациям с заказчиком? Так что взаимодействие с заказчиком может возникнуть на любом этапе разработки. Без участия заказчика получится "я туда у, а оттуда электричка"... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 13:14 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
alvaoА у программистов никогда не возникает вопросов по предоставленному ТЗ? Аналитик может дать исчерпывающий ответ на все вопросы программистов не прибегая к консультациям с заказчиком? Так что взаимодействие с заказчиком может возникнуть на любом этапе разработки. Без участия заказчика получится "я туда у, а оттуда электричка"... Одна из задач аналитика - найти компромис и "убедить" клиента в своей правоте. Никто лучше "аналитика" или "бизнес-консультанта" не должен знать как должно быть, как парвильно. Ведь клиент-то на самом то деле не всегда представляет что ему нужно. Вернее он представляет, но не обладая достаточной информацией, либо обладая искаженной - а точнее имеет свою картину мира. Достаточно редко клиент "видит" все систему в целом, ограничиваясь познаниями только лишь части функциональности. Ему в любом случае нужен "совет". Бизнес-консультант же (аналитик) должен представлять и "видеть" всю систему управления, что позволяет ему принять правильное решение и в последующем дать совет клиенту, в крайнем случае убедить в правильности своего решения. Ну по крайней мере, я так думаю, поправте меня, если я не прав, каждый уважающий себя аналитик, который строит карьеру и уверен в радужности переспективы, не должен слепо исполнять любые прихоти клиента. Он должен делать "правильно!". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 14:30 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
ФлеймерСхема слишком линейная. Заказчик должен быть вовлечен во все этапы разработки, а не ограничиваться точечным контактом с аналитиком. +1 поясню... с одной стороны клиент - первоисточник и заказчик..с другой стороны - во все тонкости отдельных фаз вникать - вряд ли будет...да и возможно помеха спецам...получаем противоречие..с одной стороны - соединить, с другой стороны - может быть только хуже... На мой взгляд разработка должна вестись "мазками" функционала. Т.е. заказчик "постоянно" получает версии программного продукта (каждый раз с более полным функционалом) с возможностью улучшения концепции, а не её изменения (хотя грань очень хрупкая)...Только тогда можно свести риски к минимуму. на самом деле данный вопрос очень тесно взаимосвязан с другими вопросами внутри фирмы производящей софт. Это и культура разработки, и правильная сформированная команда (опыт каждого члена команды. устойчивость команды), и умение и желание каждого индивидума работать на результат. очень сильно влияет архитектура управления (типичная ошибка - использование западной модели). так же не пофигу технология решения самой задачи.. и прочее, прочее, прочее... для того, что бы вести с плавным приближением к результату - нуна решить многие вопросы. Например технологию решения возникающих задач. Желательно чтоб данная технология проходила по всей "вертикали" решения, а не только в умах у программистов. на мой взгляд плавная "прорисовка" решения возможно только с нахождением тех участков логики, которые не будут меняться в дальнейшем процессе (ну или почти не будут.). т.е. более статичные весчи чем цвет и вкус заказчика... на мой взгляд технология отвечающая таким требованиям - Объектно Ориентированный Анализ и Проектирование. Именно она может способствовать фиксации сущностей от итерации к итерации... например... если заказчик ведёт речь о шиномонтаже, то явно на сцену выходят такие сущности как колёса, машины, обода, резина, грузики, нипеля и т.д. и т.п... Т.е. что бы заказчик не придумал новое - всё равно найденные ранее сущности не исчезнуть. Они могут наполниться другими глаголами и свойствами - но исчезнуть вряд ли. Т.е. они (можно сказать) для задачи - статичны. А там где статика - там простота решения и элегантность кода... это только методология... а ещё есть управление людьми. есть взаимодействие подразделений. есть автоматизация документооборота...много чаво влияет на "конвейер разработки". с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 15:05 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
методоллогия, концепуия, подходы, .... все это хорошо, господа, можно распылятся очень долго в терминологии ... а как же конкретика?! я предлагаю прорисовать схему на основании опыта работы - Вашего и моего ... Теория - это безусловно значимо, но без практического опыта ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 15:55 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
2 rubster Схему можно нарисовать очень концептуально. Методология ведения проекта, гораздо сложнее. Например, наша методология это более 100 документов, начиная от квалификации клиента и до подписания актов об оказанных услугах. Идея автоматизировать процесс использования данной методологии сталкивается с ее большой гибкостью. Например, при формализации требований Заказчика к ведению проекта, состав документации может существенно меняться. Общие концепции ведения проектов и модели разработки ПО (Водопад, Спираль, ASD, XP… ) ни кто не отменял, их достаточно много и все они обладают и достоинствами и недостатками. Управление проектом также завязано на управление изменениями, рисками и качеством. Боюсь, только в современных условиях, по моему мнению, внедрения ПО силами стажеров без достаточной базовой подготовки, сводит всю методологию к описанному выше алгоритму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 18:20 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
хочу заметить что речь не идет о компании-производителе ПО ... речь идет о компаниях, в которых разработка ПО не является источником дохода, а только лишь вспомогательной задачей для адаптации ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2006, 15:11 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Для небольших проектов, описанных rubster, я бы предложил любой возврат на этапе "Тетирования":) бизнес-консультантом согласовывать с заказчиком поскольку: 1) опытный пограммист часто логически может охватить поставленную задачу больше чем ее видит консультант 2) могут быть нарушены сроки и стоимость разработки (которые как правило, определяются аналитиком до того, как программист капнет в глубь:) 3) дополнительно может быть затронута алгоритм-логика ранее зашитая в ПО и уже испольуемая заказчиком, о которой может знать только программист Ну и конечно в целом - зависит от самих специалистов... P.S А вообще советую почитать Брукса "Мифический человеко месяц" - классика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2006, 02:12 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterметодоллогия, концепуия, подходы, .... все это хорошо, господа, можно распылятся очень долго в терминологии ... а как же конкретика?! я предлагаю прорисовать схему на основании опыта работы - Вашего и моего ... Теория - это безусловно значимо, но без практического опыта ...Наша компания, например, работает по методологии ITIL. В книжках по ITIL все схемы есть, равно как и выделены основные процессы и роли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2006, 09:50 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
UrriНаша компания, например, работает по методологии ITIL. В книжках по ITIL все схемы есть, равно как и выделены основные процессы и роли. Конечно ITIL это best, но в различных условиях, следуя казалось бы по лучшей практике, можно решать задачу значительно более сложным путем. Пример написал уважаемый Каменный Гость - он решил ее созданием более 100 регламентирующих документов. Интересно какая гибкость и оперативность при этом может быть? Неужели сотрудники помнят содержание этих документов или каждый раз ищут в них необходимый пункт инструкции? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2006, 11:09 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
erpnewsПример написал уважаемый Каменный Гость - он решил ее созданием более 100 регламентирующих документов. Интересно какая гибкость и оперативность при этом может быть? Неужели сотрудники помнят содержание этих документов или каждый раз ищут в них необходимый пункт инструкции?Ну, там же процессные подходы кругом. А процессы можно поддерживать не только с помощью административных мероприятий, но и с помощью технических решений. Программы всякие есть, в том числе и не очень плохие. Регламенты, роли, потоки зашиваются в эти программы, и уже очень много чего помнить не надо. Тем более, народу вовлечено в эти процессы очень много, и каждый сотрудник редко выступает более чем в 2-х или 3-х ролях одновременно. Так что полный перечень регламентов, конечно, существует, и его даже знают более-менее, может, несколько человек. Ну а реальные сотрудники знают само слово ITIL, имеют общее представление о том, что это такое, знают схемы процессов, в которые они вовлечены, свои роли, регламенты, которые их касаются, и контакты (смежные роли). Ну и программы много чего им, когда нужно, подсказывают. В общем, никаких особых проблем, когда все уже более-менее налажено , нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2006, 02:20 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
А вообще, с целью лучшего понимния о том, как мы должны работать, специальные тренинги (семинары) время от времени проводятся, где владельцы основных процессов презентации показывают, как их процессы построены. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2006, 02:28 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Не будет ли так любезен многоуважаемый Urri дать какие-либо полезные линки по ITIL ? было бы интересно посмотреть. спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2006, 09:50 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Может быть, здесь (я сам не читал, поэтому оценить уровень подачи материала не могу): http://krylov.lib.ru/itil.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2006, 12:07 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
Самый старый, и главное информационно насыщенный, российский форум по ITIL http://easmf.ru/cgi-bin/cutecast/cutecast.pl ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.12.2006, 15:14 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterНабрел на одной из тем форума вот на такую схему организации взаимодействия подразделений по разработке ПО rubsterГоспода, поактивнее! Думаю эта проблема актуальна для многих компаний Был в отпуске. 2 rubster Если у Вас есть вопросы конкретно ко мне то готов ответить на вопросы. Собственно по указанной мною схеме реализовывал не однократно разработку-сопровождение ПО. По развернувшейся дискуссии не понял в чем Ваш вопрос заключается. kolobok0на данном чертёжике видно, что нет ОБРАТНЫХ связей до клиента(круглый) абсолютно верно. Не являюсь автором данной схемы. Указанная схема публиковалась в открытых источниках как рекомендательная. Естественно полную схему разработки ПО как мы её создавали опубликована не может быть по коммерческим соображениям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 08:55 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
[quot velfimov] вопрос собственно в следующем: какая схема жизнеспособна? :) в приведенной мной схеме, что бы подправили? .... хотелось бы таки посмотреть на Вашу реализацию ... [quot] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 13:45 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterвопрос собственно в следующем: какая схема жизнеспособна? :) в приведенной мной схеме, что бы подправили? .... хотелось бы таки посмотреть на Вашу реализацию ... Не хочу показаться ведущим знатоком в области конвейеров по разработке ПО Но по сути дважды приходилось формировать такие конвейры. Первый раз для собственных нужд компании, второй именно для компании занимающейся разработкой и продажей ПО. У нас идиологически подход был таков 1. если аналитики, тестировщики и кодеры подчиняются одному руководителю, то он может оказывать на них давление для ускорения процесса разработки и передачи клиенту. ПМСМ это негативный фактор, отсюда, разделения на группы с подчинённостью руководителю именно по своему направлению. Согласно схемы разделение на отдел Главного конструктора(аналитики), Кодировщиков, Тестировщиков. Т.о. мы исключенили давление общего руководителя, который по определению не может быть спецом сразу в 3-х областях. 2.теперь обратите внимание отдел Главного конструктора, он разделен на 2-е части с общим руководством. Поясню, у нас сложилось разделение на системных аналитиков(СА) и бизнес аналитиков(БА). БА у нас занимались именно подготовкой ТЗ как документальное описание процессов и т.п., СА занимались моделированием ТЗ на IBM Rational (концептуальная модель и т.п.) 3.Далее весьма близко к схеме, т.е. на Вашей схеме "программист", а у нас был кодер, DB девелопер, линковщик и т.п. Не может быть человеком профи по всем областям, отсюда узкая специализация. Опять же разграничение на зоны ответственности. По Вашей схеме могу заметить отсутствие двунаправленности в стрелках. У нас движение всегда было в обе стороны для ускорения исправления ошибок. Описанная Вами схема упрощённая, как мне кажется такова д.б. для собственной разработки, а не продажи. Замечу, чем более она будет детализированна и будет разграниченна ответственность групп главного конструктора, кодеров, тестировщиков и т.д., тем более она будет прозрачна для ИТ и что главнее для вашего руководства и заказчиков. До полных моих схем тяжеловато добраться. В Мурманске всех кого я там знал разбежались по всему миру. То что делал в Твери практически идентично схеме которая Вас заинтересовала, кроме того, что ядерная группа входила в группу программистов и стрелки у нас были двунаправленны между Группами. По договорам+продажам ни чего сказать не могу, т.к. этим занимались менеджеры. В остальном схема именно была такова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 15:15 |
|
||
|
схема конвейера по разработке ПО
|
|||
|---|---|---|---|
|
#18+
rubsterвопрос собственно в следующем: какая схема жизнеспособна? Есть флотская поговорка, какой капитан так и судно поплывет Это я к тому что надо начинать с руководящих кадров. Либо обучайте своих, либо ищите спеца с таким опытом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2006, 15:27 |
|
||
|
|
start [/forum/topic.php?all=1&fid=29&tid=1527803]: |
0ms |
get settings: |
8ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
84ms |
get tp. blocked users: |
2ms |
| others: | 255ms |
| total: | 463ms |
| 0 / 0 |
