ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Пример проектирования ИС
75 сообщений из 75, показаны все 3 страниц
  все  
Пример проектирования ИС
    #35820319
Я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я
Гость
Друзья.


Помогите советом начинающему менеджеру программных проектов.
Книг по менеджменту программных проектов нашел массу.
Но там как правило только теория. Теории мало.

Нужен пример разработки информационной системы. Желательно детальный.
Буду благодарен за любую информацию по теме.
...
Рейтинг: 0 / 0
16.02.2009, 17:07
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820431
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
ЯНужен пример разработки информационной системы. Желательно детальный.
Буду благодарен за любую информацию по теме.Вы перед тем как стать менеджерам хоть чуть-чуть поработали разработчиком?
Не уж-то не участвовали ни в одном программном проекте при этом?
Соизмерьте теорию в книжках с тем что видели в жизни...
...
Рейтинг: 0 / 0
16.02.2009, 17:37
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820505
Я
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я
Гость
BelyВы перед тем как стать менеджерам хоть чуть-чуть поработали разработчиком?

Естественно опыт программерский имеется.
Но подозреваю что взгляд со стороны программера не совсем то
что нужно...
Нужен именно пример проектирования ИС со стороны менеджмента.
...
Рейтинг: 0 / 0
16.02.2009, 17:56
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820520
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Я,

Нет Коллега, на сегодня (да в-общем и всегда) управление проектов не требовало знаний собственно предмета. Ведь проект - если подумать - в любой сфере проект. Характеризуется

1. Начало
2. Продолжение
3. Конец

И всё . Хоть стенки ктрась, хить ERP пиши. Смысл одинаковый. Для первого пункта - разберись с заданием и имеющимися ресурсами. Для второго - следи за выполнением заданий и проектными рамками. Для третьего - не забудь всё доставить в срок. http://www.youtube.com/watch?v=IyNPeTn8fpo
...
Рейтинг: 0 / 0
16.02.2009, 18:02
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820547
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Это кстати Гуглисы пригласили к себе одного из самых крутых скрамеров мира. Ну против Google и методов их проектирования нигде никто ничего сказать не может. Кстати если что либо будет непонятно в плане перевода - спрашивайте.
...
Рейтинг: 0 / 0
16.02.2009, 18:16
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820630
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Mr MarmeladНет Коллега, на сегодня (да в-общем и всегда) управление проектов не требовало знаний собственно предмета. Ведь проект - если подумать - в любой сфере проект. Оно, конечно, так.
Так же как и спродажами - всеравно что продавать.
Есть только ньюансы, в которых всеравно придется кому-то разбираться.
И скорее всего - это будет PM.

Не все могут управлять незнамо чем, не представляя предметной области.

Вот, скажем, чем отличается проект постройки сортира от запуска спутника на луну?
Да ничем! Разберись с заданием:
- Чтобы сортир стоял и не падал
- Спутник должен попасть в луну

Следить за сроками:
- составил график и ставь галочки

Конец:
- Подписал акты, получил денег и гуляй
- Получил медаль, радуешься

Только не выйдет так. Точнее - МАЛО у кого выйдет так.
Потому что ньюансы везде разные.
Чтобы эффективно управлять проектом надо эти ньюансы понимать, всетаки.

авторНужен именно пример проектирования ИС со стороны менеджмента.Ну как сказать - проектирование оно и в африке проектирование.
Нужно узнать что надо (бизнес анализ), почемать репу (самому, проектировщикам или вместе с командой), выдать на гора предложение "Как будем делать".

Тонкости оформления документов - зависят много от чего, больше всего от заказчика.
...
Рейтинг: 0 / 0
16.02.2009, 18:42
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820661
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
BelyТолько не выйдет так. Точнее - МАЛО у кого выйдет так.
Потому что ньюансы везде разные.
Чтобы эффективно управлять проектом надо эти ньюансы понимать, всетаки.
.

Да нет Коллега Bely, если правильно организовать PROCESSES, подобрать правильных PEOPLE в комманду и правильно объяснить им REQUIREMENTS я никаких различий в постройке сортира и запуске ракеты на луну не вижу. Ну там бюджет - так это мелочь... Кто же нам считает.... Поэтому подборка и подготовка руководителей должна быть особенно тщательной, Но не в плане предметной области а скорее в плане постановщика - режиссёра что ли, или там прораба на стройке. Ведь согласитесь - хороший прораб запросто вкурится - туфту ему гонят или дело говорят. На каком бы "умняке" ему эту туфту не лепили...
...
Рейтинг: 0 / 0
16.02.2009, 18:52
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820748
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Mr Marmeladесли правильно организовать PROCESSES, подобрать правильных PEOPLE в комманду и правильно объяснить им REQUIREMENTSА интересно, у вас как проекты строятся - REQUIREMENTS объясняет именно PM?

Вот, к примеру, в MSF разделены полномочия Program manager и Product manager - REQUIREMENTS как раз управляет Product manager. И необходимость этого очень убедительно обосновывается.
...
Рейтинг: 0 / 0
16.02.2009, 19:29
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820764
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
alexeyvg,

Product Manager / Program Manager - и Project Manager тут у нас действительно три большие функции. По моему Аффтара интересует именно Проектирование Системы - то есть именно IS Project Manager. Или я ошибаюсь?
...
Рейтинг: 0 / 0
16.02.2009, 19:43
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35820783
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
alexeyvg REQUIREMENTS как раз управляет Product manager. И необходимость этого очень убедительно обосновывается.

Product Manager по сути своей маркетолог. Он не технарь а скорее БА. Хотя его подкованность и внимание к рынку - прежде всего технические (если мы говорим about IS) . Program Manager - я бы поставил на вторую ступень в различиях между Prouct и Project Management. Своего рода куратор проектов Ну и результирующая - как линейное звено управления будет Project Manager.

У нас в консалтинге - мы обычно справляемся одним PM .. Все проекты сам с собой и обсуждаешь.... Все задания пережёвываешь в порошок, стандарты качества определяешь Там все ворпосы и решаем. Сам с собой. Конечно замечательно если кто то есть подсобить и усмотреть ошибки... А если нет никого....
...
Рейтинг: 0 / 0
16.02.2009, 19:56
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35821539
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Mr MarmeladВедь согласитесь - хороший прораб запросто вкурится - туфту ему гонят или дело говорят. На каком бы "умняке" ему эту туфту не лепили...Вот только что делать, если туфту начнет гнать прораб с умным видом?
Кто его отсеет и остановит?

Я не говорю, что PM должен быть ЛУЧШИМ програмистом в команде, но ИМЕТЬ ПРЕДСТАВЛЕНИЕ и ПОНИМАТЬ как происходит процесс создания ПО - надо иметь.
Получить такой опыт не проработав ни минуты разработчиком - проблематично.
...
Рейтинг: 0 / 0
17.02.2009, 11:00
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35821612
Фотография krvsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krvsa
Участник
Что-то вспомнилось... Ведь всеми ядерными разработками руководил непосредственно Л.П. Берия. Не думаю что он был физиком или строителем... Но наворотили по все стране такого! Таки и бомбу сделали. И много чего еще заготовили...

Вот только руководить "все равно чем" позволительно только т.с. "людям причастным" т.е. сыночки... Протеже... И т.п...
И ведь руководят! У некоторых даже получается. А у кого и не получается - так что с того? Потом научится...
----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
...
Рейтинг: 0 / 0
17.02.2009, 11:21
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35821676
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
BelyЯ не говорю, что PM должен быть ЛУЧШИМ програмистом в команде, но ИМЕТЬ ПРЕДСТАВЛЕНИЕ и ПОНИМАТЬ как происходит процесс создания ПО - надо иметь.
Получить такой опыт не проработав ни минуты разработчиком - проблематично.

Не совсем понятно, почему PM должен иметь опыт именно программиста?

Может быть, если создаётся бугалтерская система, руководитель проекта должен быть бугалтером (аудитором, экономистом, бизнесменом)?

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

Не совсем понятно такое предпочтение именно программистам.
...
Рейтинг: 0 / 0
17.02.2009, 11:36
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35821696
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
alexeyvg[quot BelyПолучить такой опыт не проработав ни минуты разработчиком - проблематично.Не совсем понятно такое предпочтение именно программистам.[/quot]Единственное, что я могу предположить, что вы говорите не о руководителе проекта, а о техническом руководителе проекта (или архитекторе, или тим-лидере, кто как называет), т.е. о начальнике программистов.

Тогда, конечно, понятно - руководитель программистов должен иметь опыт программирования.
...
Рейтинг: 0 / 0
17.02.2009, 11:40
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35821750
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Mr Marmeladalexeyvg REQUIREMENTS как раз управляет Product manager. И необходимость этого очень убедительно обосновывается.

Product Manager по сути своей маркетолог. Он не технарь а скорее БА. Хотя его подкованность и внимание к рынку - прежде всего технические (если мы говорим about IS) . Program Manager - я бы поставил на вторую ступень в различиях между Prouct и Project Management. Своего рода куратор проектов Ну и результирующая - как линейное звено управления будет Project Manager.
Извините за любопытство - просто тема меня интересует, вот я и расспрашиваю о реальной практике...

Т.е. эта схема выглядит так:

Program Manager - это куратор где-то наверху (можно просто Бог :-) ), он раз в месяц спрашивает - "ну как там, уже всё сделали?"

Сам проект ведёт Product Manager и Project Manager

Product Manager определяет функционал, говорит, что должен представлять из себя продукт, определяет интерфейсы продукта (и расставляет всему этому приоритеты).

Project Manager определяет, что из этого функционала будет реализовано исходя из имеющегося бюджета (ресурсов) и сроков.

Разработчик (допустим, он один или это старший разработчик-лид) за уточнениями "что делать" обращается к Product Manager-у, а прогноз трудоёмкости сообщает Project Manager-у, дабы тот смог выполнять свою работу.

Правильно?

Mr MarmeladУ нас в консалтинге - мы обычно справляемся одним PM .. Все проекты сам с собой и обсуждаешь.... Все задания пережёвываешь в порошок, стандарты качества определяешь Там все ворпосы и решаем. Сам с собой. Конечно замечательно если кто то есть подсобить и усмотреть ошибки... А если нет никого....А почему у вас вместо этого один PM?

Вышеупомянутая схема чем-то плоха?
...
Рейтинг: 0 / 0
17.02.2009, 11:56
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35822101
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
alexeyvgBelyЯ не говорю, что PM должен быть ЛУЧШИМ програмистом в команде, но ИМЕТЬ ПРЕДСТАВЛЕНИЕ и ПОНИМАТЬ как происходит процесс создания ПО - надо иметь.
Получить такой опыт не проработав ни минуты разработчиком - проблематично.
Не совсем понятно, почему PM должен иметь опыт именно программиста?Я, надеюсь, мы говорим о проектах разработки / настройки ПО?
Потому что проектов несметное множество.

Проекты по созданию ЦОД.
Проекты по прокладке оптоволокна.
Проекты реорганизации сетевой инфраструктуры.
Проекты по поставке кластерных решений.
и т.д.

Это все не касаясь НЕ IT проектов. (Построить дом - это тоже проект, но строительный).

alexeyvgМожет быть, если создаётся бугалтерская система, руководитель проекта должен быть бугалтером (аудитором, экономистом, бизнесменом)?Я вам так скажу. Ему придется быть И БУХГАЛТЕРОМ И ПРОГРАМИСТОМ.
Будучи разработчиком я освоил несколько смежных спецальностей, таких как:
Метеорология (для аэронавигации), Нефтяник (буровые работы), Кассир, Бухгалтер, Оператор Call-центра, Менеджер по продажам компьютеров, Менеджер по лицензированию софта.

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

alexeyvgТем более, что в стоимости проекта программирование занимает не первое место, да и в степени влияния на результат тоже (например, определение требований имеет болшее значение, чем программирование).

Не совсем понятно такое предпочтение именно программистам.Потому что реально все упрется именно в ПРОГРАМИРОВАНИЕ.
Вот чего не стоит путать, так это КОДИРОВАНИЕ и ПРОГРАМИРОВАНИЕ.
Я говорю о программировании, как ПРОЦЕССЕ СОЗДАНИЯ ПО, а не как реализацию алгоритма сортировки на паскале/VB из учебника Кнута.

Как человек с улицы может понять, что отладка кода занимает столько же времени (а то и больше) как и его написание?
Как вы будете без этого понимания строить правильные сроки и выделять людей?
Есть три варианта:
- Поработать и понять это на своей шкуре
- Выучить это и запомнить
- Спросить у того кто это знает

Про третее - у ПМа может не оказаться такого человека, который ему растолкует все такие тонкости, если он о них не спросит. ПМ может просто оказаться последним человеком, которого спрашивают "сколько это займет времени".

Даже если вы настраиваете ERP сугубо через интерфейс, то все равно это програмирование.
Просто кодирование на языке программирования заменено на клацание мышкой в админском интерфейсе. А все остальные стадии - всеравно такие же.
...
Рейтинг: 0 / 0
17.02.2009, 13:26
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35822125
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Советую почитать две книги: DEADLINE и записки Джоэла Спольски .
Жизненно и без излишнего теоретизирования.
...
Рейтинг: 0 / 0
17.02.2009, 13:31
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35822906
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
alexeyvgИзвините за любопытство - просто тема меня интересует, вот я и расспрашиваю о реальной практике...

Т.е. эта схема выглядит так:

Program Manager - это куратор где-то наверху (можно просто Бог :-) ), он раз в месяц спрашивает - "ну как там, уже всё сделали?"

Сам проект ведёт Product Manager и Project Manager

Product Manager определяет функционал, говорит, что должен представлять из себя продукт, определяет интерфейсы продукта (и расставляет всему этому приоритеты).

Project Manager определяет, что из этого функционала будет реализовано исходя из имеющегося бюджета (ресурсов) и сроков.

Разработчик (допустим, он один или это старший разработчик-лид) за уточнениями "что делать" обращается к Product Manager-у, а прогноз трудоёмкости сообщает Project Manager-у, дабы тот смог выполнять свою работу.

Правильно?


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

Итак. Давайте я проидеализирую свою "Супер Команду". примером будет Adobe - всем известная фирма по выпуску чистого софта - мало чем похожего на Системы Автоматизированного Управления Производством.

Adobe построена по принципу - 1 команда на 1 продукт. Где то 20 (в среднем) разработчиков , 30 QA, 1 ПМ. Product manager - своего рода представитель заказчика - управляет командой QА. Project Manager - функционально следит за ресурсами и работает писателем. Ему сносят заявки на ту или иную работу, функциональность, а он определяет кто именно будет этим заниматься.

Program Manager - в своём функционале ведёт контроль проектов по выпуску на Operation System. То есть есть MAC, и Windows Programs. По иерархии - у них (Seniors) есть подкоманды - Графические тулсы, текстовые Тулсы, Видео Тулсы. То есть получается матрица своего рода вокруг команд разработчиков.

Планирование ведётся системой Водопада - от релиза к релизу. Связано это с выпуском документации на каждый релиз. Устанавливается функциональности делается прототип нового релиза и потом параллельно ведётся разработка и документирование.

Это один из традиционных методов ведения софтверного бизнеса.

Совершенно не пригоден к САУП.

:А почему у вас вместо этого один PM? Вышеупомянутая схема чем-то плоха?

теперь берём традиционный ERP (ну или АСУП) . Главным заказчиком выступает бизнес. Он диктует свои законы и комманда вся целиком подчиняется бизнесу. Внутри комманды -по новым стандартам работает так называемый SCRUM. Это термин Agile Development. Всё разбивается на маленькие итерации и De facto Project manager становится Мастером. Он следит за всем - чтобы SCRUM имел цель и результат - хоть маленький - но результат. Чтобы Бизнес - Пусть даже сам Product manager - обычно величина достаточно солидная - присутствовал на основных митингах и тем более приемке итерации и координировал обратную связь - нравится бизнесу то что получилось или нет. То есть функции Product Manager могут быть в конце концов переданы project manager если результат удовлетворительный после первых двух трёх итераций. program manager как единица координирующая всех Project managers - просто свой SCRUM MUSTER в комманде PM - а если по времени проект ограничен и не надо распылять на две - три операционки - то Program Manager просто не нужен - внутри комманды - он был и остаётся мастером. Вот такие "идеализированные" картинки получились. Вопросы?
...
Рейтинг: 0 / 0
17.02.2009, 16:44
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823002
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
BelyВот только что делать, если туфту начнет гнать прораб с умным видом?
Кто его отсеет и остановит?
Для прораба надо знать одно - цену сметы и количество людей на единицу траншеи. Если и надо "гнать туфту" то по делу - не хватает денег или "Вася совсем спился" - надо бы полечить. И диалог этот будет не в комманде а гораздо выше.


Bely
Я не говорю, что PM должен быть ЛУЧШИМ програмистом в команде, но ИМЕТЬ ПРЕДСТАВЛЕНИЕ и ПОНИМАТЬ как происходит процесс создания ПО - надо иметь.
Получить такой опыт не проработав ни минуты разработчиком - проблематично.

Я когда то имел честь работать с PM не технарями. Сам я технарь как Вы понимаете и меня провести сложнее. PM - не технарь собирает информацию внутри по принципу "расскажи как бы ты сделал этот проект" и так каждому. Задаёт удивительные по простоте и очень точные по содержанию вопросы. К Концу такого опросного дня он уже далеко не профан в предметной области. К Концу недели он даже сможет курировать выполнение стандартов. Хороший PM на мой взгляд - половина успеха проекта.
...
Рейтинг: 0 / 0
17.02.2009, 17:18
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823095
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
2Bely
Ну, может, вы и правы...
Не знаю.

Я читал книги по управлению проектами, и Спольски читал, работал сам в проектах, и у меня всё перемешивается в мозгах :-(

Я вот вижу, что описываемая Mr Marmelad-ом практика от Adobe укладывается в эти книги. И разработка проектов в Microsoft тоже укладывается. Это ведь успешные компании, продающие продукты не за откаты.

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

И вот я и думаю, чья практика практичнее - наша или импортная? Я сам не был руководителем проекта, может, поэтому и не понимаю великую тайну?

Bely
Как человек с улицы может понять, что отладка кода занимает столько же времени (а то и больше) как и его написание?
Как вы будете без этого понимания строить правильные сроки и выделять людей?
Есть три варианта:
- Поработать и понять это на своей шкуре
- Выучить это и запомнить
- Спросить у того кто это знает

Про третее - у ПМа может не оказаться такого человека, который ему растолкует все такие тонкости, если он о них не спросит. ПМ может просто оказаться последним человеком, которого спрашивают "сколько это займет времени".Да очень просто - вариант 3.

И у него не может не оказаться такого человека - иначе кто у него тогда в команде?

И вообще, не то, что просить - он и составляет эти планы со слов разработчика. Он даже не должен пытаться сам что-то оценить.

Между прочим, я считаю, что это распространённая ошибка российских прожект-менеджеров, и именно из-за того, что они бывшие программисты.

Это совершенно очевидная вещь - по определению, прожект-менеджеров менее квалифицирован своих подчинённых - просто потому, что они узкие специалисты.

Т.е. если у вас в команде 5 подчинённых (технарей, конечно; ещё 5 других):
WEB-программист
Проектировщик БД
Программист апп-сервера
Программист DirectX
Дизайнер интерфейсов
Ну, Архитектора, конечно, нет - никакой ПМ-технарь его просто не потерпит рядом с собой. :-)

И как это вы собираетесь указывать им, сколько им тратить на программирование и отладку? Вы гений, вы знаете каждую специальность лучьше каждого из них:-)

Или могу опять повторить свой тезис - вы говорите не о ПМ, а о тим-лиде - старшем программисте, у которого в подчинении 5 программистов близкой специальности и он ими руководит как старший и более квалифицированный.
...
Рейтинг: 0 / 0
17.02.2009, 17:45
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823103
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexeyvg
Участник
Mr Marmelad,

Спасибо, очень интересно. Могу сказать, что это совпадает с моими представлениями о MSF и о организации проектов в Микросфоте.
...
Рейтинг: 0 / 0
17.02.2009, 17:47
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823124
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Mr MarmeladЗадаёт удивительные по простоте и очень точные по содержанию вопросы. К Концу такого опросного дня он уже далеко не профан в предметной области. К Концу недели он даже сможет курировать выполнение стандартов.Я не спорю, что это возможно.
Вот вам аналогичные случаи:
- Sales-менеджер, переходящий в новую сферу продаж (были холодильники, теперь торгуем бриллиантами)
- Хороший Програмист - который переквалифицируется на другой язык, другую БД

Все это - ПЕРЕКВАЛИФИКАЦИЯ.
Которая реально закончится через несколько месяцев, полгода.

Второй проект у хорошего ПМ-а не технаря пойдет существенно лучше первого.

Mr MarmeladХороший PM на мой взгляд - половина успеха проекта.Это точно.
...
Рейтинг: 0 / 0
17.02.2009, 17:54
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823130
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
alexeyvdИ разработка проектов в Microsoft тоже укладывается.

Ну вот about Microsoft ничего пок асказать не могу. Мелкомягкие всё больше и больше внедряются в бизнес практику. Ещё восемь-десять лет назад от них отмахивались как от мух. Сегодня существует и отлично работает целая отрасль Microsoft Consulting services. Они сначала ставили документацию на основе MS Office, Sharepoint, Visio... etc. Потом пробивали всезде где можно SQL Server за ними пришёл BizTalk и MS Dynamics А сегодня нет отрасли в бизнес ориентированных проектах где бы не было Microsoft PM с целым пакетом стандартов от которых не так просто отказаться - отлично наработанные и поставленные процессы.
...
Рейтинг: 0 / 0
17.02.2009, 17:57
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823174
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
alexeyvgА вот российская практика не укладывается. А российская практика - это Менеджер проекта, который бывший программист и знает бугалтерию (хотя я не уверен, что пронграммист, знающий бугалтерию лучьше, как он говорит, главного бугалтера, сможет выйграть, к примеру, дело в арбитражном суде против налоговой, что ему хватит квалификации).Ну это всего лишь пьяные базары по большей части.
Но при общении с заказчиками приходится разбираться в тонкостях этого заказчика.
Отсюда много каких данных нахвататься можно.

Спольски, Билл Гейтс, Стив Джобс - технари. Но просто они пошли дальше и сейчас уже давно не технари в смысле работы.

alexeyvgИ вот я и думаю, чья практика практичнее - наша или импортная? Я сам не был руководителем проекта, может, поэтому и не понимаю великую тайну?Вы зря думаете, что у них какая-то особенная практика.

Здесь надо смотреть не на "запад-восток", а на размер компании, размер проектной команды.
Объективно - програмисту просто легче въехать в управление проектами ПО.

Если посмотрите что писал Мармелад про ПМ нетехнарей, так первое что они делают - вникают в суть работ.
BelyИ вообще, не то, что просить - он и составляет эти планы со слов разработчика. Он даже не должен пытаться сам что-то оценить.

Между прочим, я считаю, что это распространённая ошибка российских прожект-менеджеров, и именно из-за того, что они бывшие программисты.

Это совершенно очевидная вещь - по определению, прожект-менеджеров менее квалифицирован своих подчинённых - просто потому, что они узкие специалисты.Вот вы опять считаете, что я говорю о ПМ как о лучшем програмисте. НЕТ.

Давайте я поставлю вопрос по другому.
Есть проект: Надо построить и оборудовать кардиологический центр.
Справитесь?
Собственно - ничего особенного. Рисуем план, контролируем сроки, бюджет.
Но за ручку никто водить и подсказывать не будет, потому что все и так понятно - все проекты одинаковые

Аналогию улавливаете?
...
Рейтинг: 0 / 0
17.02.2009, 18:14
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823176
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
alexeyvg,

Одной из самых квалифицированных на мой взгляд Project Manager была и остаётся именно девочка из MSF. Профессионал высокого порядка. Вела 4 года проект внедрения в крупной всемирной страховой компании технологий MSF. Долгое время там был бардак и никакой логики. Все существующие платформы, все существующие системы автоматизации.. масса передублированных функций и проектов связанных с внутренней гравитацией. Одни и те же отчёты делались на 6 языках программирования из 15 различных систем. К Концу проекта всё стало на свои места. Работа велась малыми итерациями в которых строились команды PM для начала. Она их - этих project menegers научила SCRUM и вела их и ещё один на уровне Executives. Стала по функциональности Program manager. Ну ещё и mentor (толкователь) . В течение года 15 проектов по переводу систем из не-MSF в MSF системы благополучно завершились. Были созданы все процессы, набраны правильные люди, созданы и задокументированы все процедуры, введены самые современные стандарты, проведена полная реорганизация... На мой взгляд это был ее полный успех, а она даже не обратила на это внимание. Кстати съездила в Россию и удочерила девочку из Иваново. Никакого отношения к программированию не имела. но имела квалификацию PMI Institute - Модератору: - не сочтите за рекламу. Это всемирная PM организация. Кстати всё более и более на больших проектах требуются именно эта аккредитация.
...
Рейтинг: 0 / 0
17.02.2009, 18:14
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823197
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
BelyОбъективно - програмисту просто легче въехать в управление проектами ПО.

Коллега Bely, Вы знаете почему я плохой PM? мне легче сделать самому чем объяснить почему всё что сделано не будет работать... А я ЭТОГО ( делать самому) не должен ни в коей мере.... точно так же мне жалуются все достаточно серъёзные руководители - бывшие технари. Наш путь - идти в Архитекторы, Групо Лидеры, Инженеры (пусть и главные) но нолько не в project management. Мы и квалификацию свою теряем и управлять как следуем никогда не научимся... так то вот.
...
Рейтинг: 0 / 0
17.02.2009, 18:23
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823605
AlexTheRaven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AlexTheRaven
Участник
Mr Marmelad<...>Да нет Коллега Bely, если правильно организовать PROCESSES, подобрать правильных PEOPLE в комманду и правильно объяснить им REQUIREMENTS я никаких различий в постройке сортира и запуске ракеты на луну не вижу.<...>
IMHO разница есть: в рисках. Кода риски большие (много НИР, неопытная команда, требования, которые разворачиваются на 360%, сроки, которые вдруг становятся более жёсткими) - отношения к начальству и к исполнителям другое.
Маляра можно депремировать за то, что сортир красил слишком долго и некачественно - и вполне обоснованно. Да и перед начальством его сдать - нехорошо, но всё же можно.
А программиста, у которого, ну хоть убей, не получается научить компьютер распознавать в потоке людей загримированных преступников, или учёного, у которого не выходит сделать для защиты от солнечного ветра сверхмощные магниты весом в 150 кг? Бесполезно это, сплошная демотивация получается. И начальству порой приходится объяснять, что нет, нельзя гарантированно изобрести perpetuum mobile к четвергу. А вот сортир покрасить (стандартный отчётик наклепать, пару немудрёных таблиц сделать) - можно.
У Берии и Королёва, конечно, получалось, но... не слишком ли дорогой ценой? "Пережгли" команды учёных, в результате так полвека в ВВРах уран и варим, да на королёвских "семёрках" в космос ползаем.
...
Рейтинг: 0 / 0
18.02.2009, 00:44
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35823908
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Mr MarmeladBelyОбъективно - програмисту просто легче въехать в управление проектами ПО.

Коллега Bely, Вы знаете почему я плохой PM? мне легче сделать самому чем объяснить почему всё что сделано не будет работать... А я ЭТОГО ( делать самому) не должен ни в коей мере.... точно так же мне жалуются все достаточно серъёзные руководители - бывшие технари. Наш путь - идти в Архитекторы, Групо Лидеры, Инженеры (пусть и главные) но нолько не в project management. Мы и квалификацию свою теряем и управлять как следуем никогда не научимся... так то вот.
+1
:)
у программистов потолок (за редким исключением).
IMHO уметь программировать PM только вредит... А программистам и архитектору - это его ПОЛУумение мешает.
...
Рейтинг: 0 / 0
18.02.2009, 10:00
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35824144
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Bely
Участник
Petro123IMHO уметь программировать PM только вредит... А программистам и архитектору - это его ПОЛУумение мешает.Надо не уметь програмить, а понимать процесс производства ПО, его особенности, возможные риски.
Не надо пытаться сделать самому - это и есть ошибка, а не то что ПМ это програмист.
ПМ - это функционер и организацтор, который еще понимает в ПРОЦЕССЕ производства ПО и в смежной области для которой ПО делается.
Если человек ни разу не видел этого процесса, то прежде чем он сможет реально руководить таким проектом ему во все это придется въехать.
...
Рейтинг: 0 / 0
18.02.2009, 11:27
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35824190
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
BelyPetro123IMHO уметь программировать PM только вредит... А программистам и архитектору - это его ПОЛУумение мешает.Надо не уметь програмить, а понимать процесс производства ПО, его особенности, возможные риски.
Не надо пытаться сделать самому - это и есть ошибка, а не то что ПМ это програмист.
ПМ - это функционер и организацтор, который еще понимает в ПРОЦЕССЕ производства ПО и в смежной области для которой ПО делается.
Если человек ни разу не видел этого процесса, то прежде чем он сможет реально руководить таким проектом ему во все это придется въехать.

я согласен, только он не должен знать что такое переменная и классы, а также как сделать "формочку" и т.д.
Т.е. лучше бы он не работал программистом в 1945 году.

Для понимания ПРОЦЕССА есть графа опыта в резюме.

ЗЫ. Если из балерины вышла неплохая актриса, это значит... что она просто ... не была балериной.
...
Рейтинг: 0 / 0
18.02.2009, 11:39
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35825412
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
BelyНадо не уметь програмить, а понимать процесс производства ПО, его особенности, возможные риски.
..........
Если человек ни разу не видел этого процесса, то прежде чем он сможет реально руководить таким проектом ему во все это придется въехать.

Ну вот тут Вы абсолютно правы. Надо знать ПРОЦЕССЫ и иметь отличную КОМАНДУ. Надо следить за опытом накопленным другими PM (что и делает кстати аффтар начинающий PM), и главное - немедленно определить где зерно а где семя. Или что там в сельском хозяйстве отделяют.... Извините - не моя область ... Посмотрите на Президентство (России, США, Франции....) - тоже своего рода PM. и мало у кого есть опыт управления ТАКИМ проектом...
...
Рейтинг: 0 / 0
18.02.2009, 17:29
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35883910
Алекс0349
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алекс0349
Гость
ЯДрузья.


Помогите советом начинающему менеджеру программных проектов.
Книг по менеджменту программных проектов нашел массу.
Но там как правило только теория. Теории мало.

Нужен пример разработки информационной системы. Желательно детальный.
Буду благодарен за любую информацию по теме.

Не совсем понятно, что Вас интересует ? Проектирование ИС или проектирование ПО для некой ИС?
Это разные вещи. Проектирование ИС значительно шире, чем проектирование ПО для ИС.

Или просто проектирование ПО ? Бывает так что и проектировать ничего не нужно.
Вы нам тут переведите из FoxPro 2.6 на 1С 7.7 !!
...
Рейтинг: 0 / 0
22.03.2009, 08:53
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35883997
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Если пустить руководителя по проектированию туалета на создание модуля полета на луну, то в лучшем случае получим летающий сортир.
Автору проще поискать в городе работающие фирмы с маленькими проектами и посмотреть как это все проходит. При чем оценку производить не по удачам, а по провалам (в срок не уложились потому что... и что бы этого не повторилось нам нужна дополнительная роль...)
От себя замечу: далеко не каждый проект состоит из 3-х стадий и ролей часто бывает больше 10 (кроме сверх маленьких проектиков).
...
Рейтинг: 0 / 0
22.03.2009, 12:33
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35886087
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467Если пустить руководителя по проектированию туалета на создание модуля полета на луну, то в лучшем случае получим летающий сортир....

Предисловие: Хорошие летающие туалеты ещё никому не помешали...

Коллега Enot5467 - Конечно можно иметь сотню стадий на каждом проекте и десятки ролей непонятно зачем и кому это надо. Таковой - если мне не изменяет моя knowledge base - и была в период "развитого сюрреализма" - система передовой социалистической экономики, когда топтание на месте (ну или бегом по кольцу - "начала нет и нет конца") очень часто называли прорывом в светлое будующее. Посмотрите: если проект не начался ( а тем более не закончился) - именно так и будет - движения нет и если оно есть - то ни к чему чаще всего не приведёт.

Только исходя из этого ( во имя завершения начатого дела) мы и делим всё на три стадии:
1. начало
2. продолжение
3. конец

Каждую отдельную фазу мы тоже называем проектом и ее разбиваем на три стадии и так далее. Конечно суммарно может быть сотни началов и концов (каждой фазы) , но без них.... Никак. Если Вы Коллега внимательно посмотрели презентацию по скрам - вы бы убедились что это всё спиральное движение - начало новой фазы очень часто по времени совпадает с концом предыдущей и так далее - Таким образом мы не бегаем по кольцу а всё таки движемся вперёд...
...
Рейтинг: 0 / 0
23.03.2009, 16:11
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35886659
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr Marmelad,

Все ни чего, только схема с началом и концом нормально уживается в проектах, где есть разделение между ними и отсутствуют множественности стадий. Если по русски, то вход можно представить входом, а можно продолжением (ответвлением) другого процесса. В зависимости от взгляда может поменяться полностью все планирование. Поэтому не компетентный руководитель может завести весь проект в такие дебри... конечно, потом виноваты будут все остальные.
Кстати, схема "начало, продолжение, конец" это вроде как стандарт продажников, а не руководителей проектов.
Десятки непонятных ролей и десятки неправильных ролей, это разные вещи. К сожалению даже маломальский проект в первый же месяц покажет весь список ролей. Гораздо эффективней предусмотреть все роли и распределить их между имеющимися сотрудниками (на каждую роль свою степень ответственности), чем пытаться в последствии растыкивать появившиеся потребности. Это как делать деталь по чертежу: за ранее продумываются размеры и алгоритмы изготовления, вместо того, что бы все это уточнять когда она уже под фрезой.
Очень интересно развивать эту науку на ошибках соседей. Например продукт немного неудачный, потом выясняется, что забыли про роль "тестер". В итоге тестировал сам разработчик, что в корне не верно и гарантировано наличие ошибок, т.к. разработчик думает как сам код.
В общем повторюсь еще раз: автор, лучше посмотри на провалы соседей и посмотри, что они сделали не так.
P.S. Совсем забыл, в моей копилке уже есть примеры удачных и неудачных проектов, а так же работа с продажниками в качестве руководителей и с руководителями ни чего не понимающих в специфике предметной части проекта. Поэтому могу позволить себе немного поспорить
...
Рейтинг: 0 / 0
23.03.2009, 19:15
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35886688
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467Кстати, схема "начало, продолжение, конец" это вроде как стандарт продажников, а не руководителей проектов.

Опять тут меня прилипили к какому то клейму... Моя переводческая система научилась фиксировать отторжение функций продаж. Коллега Enot5467 вся беда пост-советского бизнеса в том что Вам никак не удаётся понять что ПРОДАЖИ - Первичны. И Все мы всё продаём. ВСЕ - от мала до велика. Мы ничего плохого не делаем. Торговля - сама по себе это хорошо. Непонимание и Ругань - плохо. Усвоили?

Далее.

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

Пы Сы . Замечание по поводу тестера в команде - принимается безоговорочно. Их должно быть столько же и больше чем разработчиков. Тогда продукт (Сервисный продукт ПО) становится компетентным
...
Рейтинг: 0 / 0
23.03.2009, 19:43
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35887373
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr Marmelad,

Вот то, что мне пришлось для себя уяснить:
Проект, так же как и любой процесс можно представить в рамках разных моделей. В том числе часто используется модель вх.данные->объект->результат, что соответствует схеме "старт-тело-конец". Не буду скрывать, первые проекты мы пытались тоже делать так же. Потом методом проб и ошибок пришли к выводу, что у любого процесса/объекта есть еще управляющее воздействие и ресурсы/инструменты. Сейчас мы работаем по второй схеме, ошибок и провалов стало в разы меньше. В данном случае избыточность не помешала.
Дальше: Если пришел продажник и продал учетную систему, это одно. А вот если 2 фирмы уже есть на проекте и мы чуть ли не сбоку подходим (с учетом, что одной из фирм уже несколько лет помогаем в этом проекте), делаем отдельную часть и передаем одной из фирм по окончанию. Потом через год опять берем свою часть и дорабатываем в соответствии с "хотелками" заказчика. Вот в этой схеме нет четкого старта и конца. Плюс тело (продолжение) очень бесформенное получается. Но это можно увидеть только если смотреть глазами разных специалистов. Конечно, любой псевдоспециалист сразу же очертит границу и... хорошо, если угадает, в противном случае и себя завалит и соседние 2 фирмы-партнеры.
Теперь опять про роли: роль "тестер" я привел не с проста, а для указания, что и другие роли если возникает понимание, становятся крайне необходимы. Именно из таких рассуждений я утверждаю, что на проектах средних и выше присутствует более 10 ролей, каждая из которых обоснованна "от-и-до"
Кстати, различия услуг и товаров очень не плохо расписывается во внедрении итилиума. Автору советую почитать сей немудренный документ, там ооочень много интересного по ведению проектов на основе опыта многих компаний. Там же рассматривается одна из моделей представления проекта "умным языком"

Мне кажется беседа уже зашла в какое-то переперательство, так что предлагаю немного сбавить темп и, при желании, рассмотреть обе схемы со стороны плюсов и минусов. Но только если это хоть как-то поможет автору
...
Рейтинг: 0 / 0
24.03.2009, 10:24
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35887455
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467,
не могли бы Вы чуть яснее выразить структуру проекта, о которой рассказываете. По тому что Вы описали видно, что есть и начало и конец и тело проекта. Или Вы просто то, что описали как "доработка" не выделяете в отдельный проект.
Соглашусь с Mr Marmelad по поводу последовательной детализации и разработки проектов.
...
Рейтинг: 0 / 0
24.03.2009, 10:47
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35888348
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Mr Marmelad
Вы не совсем удачно привели пример с чертежом детали. Чертёж детали - установленный и утверждённый - часть целой системы которую можно потрогать и если деталь не соответствует чертежу вся сборка не будет работать. В Этом и есть главное различие нас (IT) от механиков. У них ПРОДУКТ у нас - СЕРВИС.
+1
Мартин ФаулерЧертежи, где представлены отдельные элементы строительства, ложатся в основу подробного чертежа, который позволяет определить конкретные задачи и зависимости между ними. А это, в свою очередь, дает возможность рассчитать стоимость и временные рамки строительства. Кроме того, здесь же подробно описывается, каким образом строители должны делать свою работу. Благодаря этому работа строителей становится еще менее интеллектуальной, хотя, разумеется, нередко требует очень хороших навыков ручного труда.

Итак, в данном случае перед нами два совершенно разных вида деятельности. С одной стороны, проектирование, которое является трудно прогнозируемым процессом, и для которого требуются дорогостоящие творческие специалисты, с другой - конструирование, которое прогнозировать гораздо легче . Как только проект готов, можно планировать конструирование. Как только готов план, конструирование становится вполне предсказуемым процессом. В гражданском строительстве фаза конструирования гораздо масштабнее, нежели проектирование и планирование - как с точки зрения бюджета, так и по времени.
http://www.maxkir.com/sd/newmethRUS.html
...
Рейтинг: 0 / 0
24.03.2009, 14:36
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35888744
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Я думаю что мы говорим об одних и тех же вещах. Просто Коллега Enot5467 утверждает что на средних и больших проектах базисная структура может быть "нагружена" Контролем и Планированием как это показано на рисунке. На мой взгляд спорное представление но ничего против такого решения я лично не имею. Да контроль нужен. Да планирование - очень помагает качеству системы. Но по сути мы вё это делаем и так. Во время движения проекта к завершению.
...
Рейтинг: 0 / 0
24.03.2009, 16:16
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889630
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Petro123: Наверное я неправильно выразился по аналогии с деталью. Данное сравнение было сделано только для показа важности планирования ролей, а не схожести продаж продуктов и услуг.
Mr Marmelad: Про остальное, скорее тут опять у нас немного недопонимание из-за разных источников информации. Представление процесса "начало-тело-конец" очень удачное решение, но не для предоставления ИТ услуг. Конечно, ту схему которую я пытаюсь описать тоже можно заключить в эти рамки, но при этом разные руководители по разному установят границы между стадиями. Например стадию "начало" будет сложно определить для описанного примера в прошлом моем сообщении. Конечно, сейчас любой сможет провести эту границу, но, если потом сравнить 2 мнения от людей разной квалификации, то выяснится, что понятие "начало" будет разным. Уверяю, именно это и сказывается на проблемность проектов.
Если принять модель процесного подхода ISO9000, то можно значительно сократить "провалы" и, как следствие, увеличить КПД всей деятельности. Именно согласно этому стандарту кроме цепочки "начало-тело-конец" имеется еще упр.воздействие и ресурсы. В этой схеме проще оперировать "непонятным началом" или несколькими стартами на языке доступном и бывшему программисту и простому бухгалтеру. Мое несогласие вызвано тем, что в приведенной Вами схеме трудно учесть распараллеливание, например начала или размытость границы между телом и концом. Хотя, может я и ошибаюсь.
По моему личному мнению, что бы выбрать вариант представления процесса, надо испробовать обе схемы, но лучше все таки посмотреть со стороны какая надежней. Хотя может и лучше "на своей шкуре" пробовать все.
...
Рейтинг: 0 / 0
24.03.2009, 22:24
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889655
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Petro123,

По Вашей ссылке много интересного. Но опять же не до конца согласен, из-за чего не могу опираться на данный источник, как на авторитетный. Если я правильно понял, то автор текста за основу взял дискретное представление отношений заказчика с исполнителем, при этом "уходы в сторону" он тоже пытается описать в рамках своей теории. Тогда как мне кажется необходимо за основу брать приближение. Например фраза:
" ...Процедура известна: вы объясняете компании-разработчику, что нужно сделать, они называют цену, вы ее принимаете, после чего вся ответственность ложится на плечи разработчиков, которые должны создать требуемый программный продукт... "
почти сразу приведет к неудаче. Это отношение необходимо рассматривать со стороны разности опыта и представления (своего рода карты мира) обеих сторон. Если изначально это предусмотреть, то можно максимально минимизировать риски непопадания в обозначенные границы. Согласно теории автора конечная точка определяется заказчиком и до конца проекта, по возможности, она должна быть неизменна, хотя я точно уверен, что эта конечная точка будет располагаться далеко не там, где ее изначально располагает заказчик. Для подтверждения моих слов достаточно просто сравнить на любом оконченном проекте, что хотели и что получили, а после попробовать смоделировать весь ход событий заново.
Может я не правильно понял идею "новой методологии программирования", но ИМХО, не желательно сей документ брать за основополагающий особенно при начале карьеры в проектной деятельности.
...
Рейтинг: 0 / 0
24.03.2009, 22:45
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889665
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467,

Коллега, я так и не увидел альтернативы - если вы считаете многовходовость в тело ПРОЦЕССА чем то другим - пожалуйста, но это ничего не меняет. Всё равно есть только одно начало - скажем так: ЗАКАЗЧИК СКАЗАЛ "ХОЧУ" а уж сколько там команд внутри этого ЕДИНОГО начала пошло поехало делать ЭТО ХОЧУ - какая разница? всё равно только ОДИН результат будет принят и тогда ЗАКАЗЧИК СКАЖЕТ "ГОТОВО" и выплатит денюшку. А между этими НАЧАЛОМ и КОНЦОМ - да хоть 25000 человекочасов - если работа сделана - она должна быть оплачена. Понятное дело не всем командам, а той, чьё решение {или "костюнчик"} сшитo качественно и в срок
...
Рейтинг: 0 / 0
24.03.2009, 22:50
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889671
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467 Согласно теории автора конечная точка определяется заказчиком и до конца проекта, по возможности, она должна быть неизменна, хотя я точно уверен, что эта конечная точка будет располагаться далеко не там, где ее изначально располагает заказчик.

Совсем нет - Заказчика мудрая команда разработчиков сажает вместе с собой и каждый раз спрашивает ( на основе маленькой итерации) ЭТО ИМЕННО ТО ЧТО ВЫ ХОТЕЛИ? Ответ или ДА или НЕТ - и так каждый раз. Пока не будет готов весь ПО ПРОДУКТ = СОФТВЕРНОЕ РЕШЕНИЕ .
...
Рейтинг: 0 / 0
24.03.2009, 22:56
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889683
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Но опять же повторюсь - это "SCRUM" методология подходит к проектированию ERP - бизнес зависимых систем. Никакого отношения к "коробочным" решениям типа WinZip, TextPad, Adobe и так далее не имеющее. Там заказчик - все мы - и чем больше нас - потребителей - у этого изготовителя тем прямолинейнее процесс. Спиральность процесса поставки характерна в бОльшей мере именно Бизнес Решениям или Management of Information Systems. у MIS заказчик - Бизнес, а бизнес вещь тонкая....
...
Рейтинг: 0 / 0
24.03.2009, 23:04
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889704
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr Marmelad,
Я понимаю Ваше негодование. Просто мне самому интересна "идеальная" схема проектной деятельности, поэтому я пытаюсь найти для себя что-то новое.
Я не пытаюсь представить альтернативу Вашего "начало", а лишь показываю, что линейная схема "начало-тело-конец" является не совсем эффективной. И доказательства этому множество неопределенностей и размытостей. Представленная мной схема процесса (проект же тоже процесс?) многие неточности перекрывает, хотя и не все.
...
Рейтинг: 0 / 0
24.03.2009, 23:19
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889744
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467Представление процесса "начало-тело-конец" очень удачное решение, но не для предоставления ИТ услуг.
а что с ИТ услугами не так? у них нет тела или нет конца? Непонятная мысль
...
Рейтинг: 0 / 0
25.03.2009, 00:07
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889747
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467"вы объясняете компании-разработчику, что нужно сделать, они называют цену, вы ее принимаете, после чего вся ответственность ложится на плечи разработчиков, которые должны создать требуемый программный продукт..."
почти сразу приведет к неудаче.
не факт. разве что вы посторонним людям пытались объяснить того, чего они не понимают.
...
Рейтинг: 0 / 0
25.03.2009, 00:09
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889750
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467Mr Marmelad,
Я понимаю Ваше негодование. Просто мне самому интересна "идеальная" схема проектной деятельности, поэтому я пытаюсь найти для себя что-то новое.
Я не пытаюсь представить альтернативу Вашего "начало", а лишь показываю, что линейная схема "начало-тело-конец" является не совсем эффективной. И доказательства этому множество неопределенностей и размытостей. Представленная мной схема процесса (проект же тоже процесс?) многие неточности перекрывает, хотя и не все.
Вы упустили самую главную высказанную коллегой Mr.Marmelad мысль об итерациях . Схема не линейная, она иерархическая. Представьте проект где более 1000 стадий, а на каждой стадии NN операций. Постепенно, углубляясь... Но постоянно есть начало-тело-конец. Кстати о какой представленной Вами схеме речь идет?
...
Рейтинг: 0 / 0
25.03.2009, 00:16
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889839
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm
а что с ИТ услугами не так? у них нет тела или нет конца? Непонятная мысль
В этой схеме не излишество, а нехватка
...
Рейтинг: 0 / 0
25.03.2009, 06:23
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889843
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm не факт. разве что вы посторонним людям пытались объяснить того, чего они не понимают.
Рассмотрите сей момент со стороны разности представления. Мы и сейчас с Вами общаемся по абсолютно разным представлениям, т.к. у нас опыт разный. Для примера попробуйте по очереди 10 человекам задать вопрос "что такое чакра". После получения ответов вы поймете, что люди воспринимают слова в меру своего опыта, не более. Это очень сложная тема и, мне кажется, здесь нет смысла ее разводить.
Ну а что бы ближе к нашей теме быть, то просто смоделируйте у себя в голове часть проекта при условии, что заказчик вам обозначит проблему "моя бухгалтерия не вовремя сдает НДС". С чего Вы начнете? С точки зрения заказчика, он Вам обозначил конкретную проблему.
...
Рейтинг: 0 / 0
25.03.2009, 06:32
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35889848
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm
Вы упустили самую главную высказанную коллегой Mr.Marmelad мысль об итерациях . Схема не линейная, она иерархическая. Представьте проект где более 1000 стадий, а на каждой стадии NN операций. Постепенно, углубляясь... Но постоянно есть начало-тело-конец. Кстати о какой представленной Вами схеме речь идет?
Я представляю описание процесса отличное от "начало-тело-конец", а вы пытаетесь меня завести в рассуждения о декомпозиции процесса и итерационном подходе. Схему я описывал ранее:
" ...Именно согласно этому стандарту кроме цепочки "начало-тело-конец" имеется еще упр.воздействие и ресурсы... "
Это же просто, только надо попробовать руками.
Еще раз повторю: схема озвученная Mr.Marmelad, по моему мнению, является менее эффективной по сравнению схемы, которую описываю я. И эффективность обозначается не "что-то убрать", а наоборот "что-то добавить".
Именно в этот раз мы говорим всё таки о разных вещах
...
Рейтинг: 0 / 0
25.03.2009, 06:39
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35890567
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467заказчик вам обозначит проблему "моя бухгалтерия не вовремя сдает НДС". С чего Вы начнете?
с выяснения причин, которые мешают бухгалтерии вовремя сдавать отчетность по НДС.

p.s. про чакры и опыт не въехал
...
Рейтинг: 0 / 0
25.03.2009, 13:13
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35890582
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467Схему я описывал ранее:
" ...Именно согласно этому стандарту кроме цепочки "начало-тело-конец" имеется еще упр.воздействие и ресурсы... "
Это же просто, только надо попробовать руками.

воздействия и ресурсы есть и в начале, и в теле, и в конце. Вопрос отсюда и возник... в чем отличиеь или суть
...
Рейтинг: 0 / 0
25.03.2009, 13:17
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35890891
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm,
Попробуйте дайте задачу выяснения сначала программисту, а потом, например, миллиционеру. Когда сравните результаты, будете сильно удивлены. Скорее всего, программист полезет в учетные системы, будет изучать их ПО сдачи налоговой отчетности. С другой стороны миллиционер начнет со стороны штрафов и поощерений + зацепится за внутренний документооборот. Самое обидное, что в конце выяснится факт, что необходимо, например, одного человека просто поставить на контроль подачи документов от поставщиков. Это реальный пример исход которого сказать не могу. Замечу только, что после окончания мы поняли, что начал было много, нам увиделось только одно. Как результат почти месяц решения непонятно чего. Если проводить оценку упр.воздействия и инструментов, то можно сразу сузить круг поиска и уменьшить количество вероятных "начал", потому что вопрос ставится не со стороны "давайте стартовать с того, что знаю", а со стороны оценки "что имеем и как влияет на черный ящик". Если бы мне раньше попались соседи с таким опытом, то, скорее всего, не попались бы на подобном, поэтому я и советую автору предварительно приглядеться к уже проваленным проектам и только после выбирать удобную схему представления процессов.
Все! Мне кажется это все лишнее. Предлагаю на этом закончить обсуждение. А тем кто сомневается, что существует не одна схема могу только посоветовать почитать тот-же ISO9000 (уже не помню какой именно и могу ошибиться, вроде 9001).
...
Рейтинг: 0 / 0
25.03.2009, 14:38
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35890936
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467
Попробуйте дайте задачу выяснения сначала программисту, а потом, например, миллиционеру.
зачем? Для этого есть аналитик . Я удивлен предложением дать эту задачу на рассмотрением совсем посторонним людям. Загадки какие-то.

p.s. жаль что Вы ушли от обсуждения, так и не вступив в него и прояснив свою позицию. Все вопросы так и повисли в воздухе, к сожалению.
...
Рейтинг: 0 / 0
25.03.2009, 14:50
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891127
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafmp.s. жаль что Вы ушли от обсуждения, так и не вступив в него и прояснив свою позицию. Все вопросы так и повисли в воздухе, к сожалению.
Я ни куда не ушел, просто мне кажется мы говорим и не понимаем друг-друга.
Кстати про аналитиков: я привел пример не для того что бы показать, чем отличается один рабочий от другого, а для показа различия подхода людей к решению задачи в зависимости от своего опыта. Просто представлены 2 крайние точки. Мне казалось это наглядный пример. Хорошо, возьмите 2-х аналитиков, но из разных компаний и найдете тоже различия во взглядах. У них же опыт будет разный тоже. По схеме предложенной мой не исключается 100% исчезновение ошибок, но гораздо уменьшается их количество.
А вопросы я поднял всего 2:
1. Роли надо планировать за ранее и их всегда гораздо больше 3-х
2. Схема описания процесса "начало-тело-конец" является не эффективной по сравнению с альтернативной, которая с первого взгляда всего дополнена двумя понятиями, а при детальном рассмотрении меняет сильно варианты решения задач проектной деятельности.
После я попытался (в рамках своей неуклюжести) привести примеры и ссылки на источник, на который оперался.
Скажем так: на этих примерах я сам учился, поэтому может мне и кажется все очевидно просто
...
Рейтинг: 0 / 0
25.03.2009, 15:24
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891189
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467,

Я тоже тщетно пытался разобраться на каком нибудь приведённом примере ЧТО ЖЕ такое - эта Ваша "альтернативная система" Кроме "на ошибках других проектов" учатся - ничего не нашёл. Мне кажется Коллега Вы сами усложнили свои проекты. А логика скарама и еджаил ( SCRUM & AGILE ) сводится как раз к противоположному - УПРОЩЕНИЮ. В Одной итерации - ITERATION{а ею может быть даже один день работы всей команды.
Пример : Заказчик утром "вспомнил" что надо новый рапорт о сдаче НДС в конце дня автоматически посылать всем бизнес оунерам.
В Команде
сели покумекали что делать разбежались --НАЧАЛО

к обеду собрались с идеями --ПРОДОЛЖЕНИЕ

после обеда закодировали, убедились что всё работает --ПРОДОЛЖЕНИЕ

загрузили в сорс контроль - --ПРОДОЛЖЕНИЕ

сделали билд и --ПРОДОЛЖЕНИЕ

отдали тестерам на проверку а сами --ПРОДОЛЖЕНИЕ -->> КОНЕЦ

пишут документацию --КОНЕЦ --> -- Начало НОВОЙ ИТЕРАЦИИ}
- можно увидеть все фазы ведения именно этого кусочка - "забыли про НДС". День работы и назавтра доклад клиенту - ГОТОВО, проверяйте.
...
Рейтинг: 0 / 0
25.03.2009, 15:38
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891251
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Кстати сказать о составе команды- на каждую итерацию она может быть разной. В случае с репортом - это
автор
аналитик,

архитектор,

DBA( даже несколько если система собирает данные из 5 разных ресурсов -
--DB-2,
--SQL Server и
--Oracle
--(XML + Flat Files) и рассылает корпоративной
-->-- IBM Lotus Notes почтой,

рапортовый кодировщик ну например CrystalReports или SSRS.

Другой случай допустим - новую колоночку надо ввести во все ресурсы Например дату изменения значения в записи. - там заправлять будут Проектировщики баз и архитекторы, код будет выдан [всем] DBA для внедрения и так далее...
...
Рейтинг: 0 / 0
25.03.2009, 15:53
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891270
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467
1. Роли надо планировать за ранее и их всегда гораздо больше 3-х


Может быть и один человек - например писака документации - всё что ему надо - писать писать и писать - на 3-х - 5-ти языках Его то и тестировать труднее всего - ну нет у меня сейчас никого кто понимает японский... И где взять?
...
Рейтинг: 0 / 0
25.03.2009, 15:58
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891353
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr Marmelad,

Вы и в правду издеваетесь? Посмотрите описание процесса по ISO9000. Итерации идут совсем в другом разрезе. Мы сейчас обсуждаем виды представлений процессов. Если честно, то я уже боюсь на итерации переходить
Теперь про упрощение: Экскаватор однозначно сложнее лопаты, при этом он не является лишним. В принципе яму можно и лопатой выкопать (или лопатами), только не эффективно будет. Я к тому, что "сложное" и "не понятное", это всё таки разные вещи.
...
Рейтинг: 0 / 0
25.03.2009, 16:17
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891389
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467,

Я правду очень хочу понять Коллега, чесслово. Над ISO9000 - поверьте мне - я работаю более 15 лет, но без специальной ссылки мне там делать нечего. Пурга ... Я очень очень хочу Вас понять - но наверное моя переводческая система чего то упускает. Чесслово - Вот давайте так - я человек с Америки. Русский мой очень лимитированный. Ккак бы Вы объяснили мне при встрече особенности вашего метода?

Nota Bene: Надеюсь мои объяснения итерационного подхода к управлению проектами понятны - если нет - задайте вопросы - попробую ещё раз

Note: I am even dropping the smoking fase for you to make you feel that I really do want to understand.
...
Рейтинг: 0 / 0
25.03.2009, 16:30
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891412
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr Marmelad,

:)) шутите? Это уже гораздо лучше, раз шутите
Итерационный подход понятен, мы ни в коем случае не упускаем эти знания. А по ссылке... к сожалению я не знаю, где такое в инете есть. Но вот сам документ в кратком изложении по проектной деятельности на примере внедрения одного из ПП у меня есть. Не буду кривить душой, именно от туда мы и развивали комплекс внутрикорпоративных стандартов по проектной деятельности. (краткость его заложена в 90 страницах). По правде мне самому при прочтении подобной документации на 20-й странице спать хочется, так что лучше 1 раз увидеть. К тому же там написано языком понятным для всех, а не как я: только для себя и со стороны своих взглядов.
Если кому интересно, могу выслать в индивидуальном порядке
...
Рейтинг: 0 / 0
25.03.2009, 16:39
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891425
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
с одной стороны про проекты, с другой про процессы. Действительно, как можно в такой каше что-то понять.
...
Рейтинг: 0 / 0
25.03.2009, 16:42
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891456
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr MarmeladКстати сказать о составе команды- на каждую итерацию она может быть разной. В случае с репортом - это
автор
аналитик,

архитектор,

DBA( даже несколько если система собирает данные из 5 разных ресурсов -
--DB-2,
--SQL Server и
--Oracle
--(XML + Flat Files) и рассылает корпоративной
-->-- IBM Lotus Notes почтой,

рапортовый кодировщик ну например CrystalReports или SSRS.

Другой случай допустим - новую колоночку надо ввести во все ресурсы Например дату изменения значения в записи. - там заправлять будут Проектировщики баз и архитекторы, код будет выдан [всем] DBA для внедрения и так далее...

А мне казалось, что список ролей описывается единожды (потом только дополняется), а по мере поступления заданий они все распределяются среди существующих сотрудников.
Вот в Вашем списке нет тестера! Хотя, я уверен, он просто совмещен с другими ролями, например с аналитиком. Это я к тому, что при уменьшении задачи роли ни куда не исчезают, они просто совмещаются в одном человеке.
Чем такая схема удобнее? Как мимнимум можно определить зоны ответственности, оплату, функ-ие обязанности и т.д. Потом, при необходимости совместить, сотрудник будет конкретно знать на что идет, сколько это стоит и сколько он получит за провал.
Если использовать именно "исчезновение" ролей, то уже сложнее определить хотя бы ответственность. Убрали тестера, получился проектик хреновый. Кто виноват?
Что-то такое вроде должно быть
...
Рейтинг: 0 / 0
25.03.2009, 16:52
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891459
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
iscrafm
Участник
Enot5467, наверное имеются ввиду не стадии проекта , а схема процесса его выполнения?
стр.5 на русском
стр.12 на английском
...
Рейтинг: 0 / 0
25.03.2009, 16:52
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891484
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm,

Хех, мне всегда казалось, что это одна сущность. Цитирую:
"Процесс - это логически взаимосвязанная между собой последовательность работ, видов деятельности". Мне кажется очень даже и не плохо вписывается в проект. Мало того, некоторые источники так представляют объекты! Т.е. для них объект, процесс и проект одно и тоже. А именно проект это процесс, а процесс это объект (как-то так). Если честно, то мне это еще пока самому немного сложно для понимания.
Хотя, если у Вас есть доводы по разделению этих 2-х понятий, то мне было бы интересно их увидеть/услышать
...
Рейтинг: 0 / 0
25.03.2009, 16:58
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891505
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
iscrafm,

Именно!!!!!!
...
Рейтинг: 0 / 0
25.03.2009, 17:02
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891535
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
только я там не нашел примерно такие строки:
"...Так как качество услуги может меняться во времени, важным вопросом становится возможность оказания услуги с постоянным качеством. Как этого достичь? Общепринятой моделью организации деятельности с целью построения системы качества является процессный подход, и модель ISO 9000. (В настоящее время ISO 9001:2000 и еще целый ряд моделей и стандартов.)
Процесс - это логически взаимосвязанная между собой последовательность работ (видов деятельности (activities), направленная на достижение поставленной цели. Каждый процесс имеет вход, выход, управляющее воздействие, и потребляет некие ресурсы. Вся деятельность организации представляется в виде процессов. Здесь же кроется сложность использования процессного подхода: сложность привязки его к организационной структуре..."
...
Рейтинг: 0 / 0
25.03.2009, 17:10
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891553
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467Вот в Вашем списке нет тестера!
........
Убрали тестера, получился проектик хреновый. Кто виноват?

Коллега, Отдел Технического Контроля - это одна из наиважнейших частей нашей работы. Вот в этой ветке я попытался обозначить как работает такая команда. Кстати и вот этот пост нашего топика подчёркивает необходимость QA. Когда упоминается шаг "Отдать Тестерам" - значит не вернуть его в команду а показать "представителю заказчика" которым и является QA на время выполнения проекта.
...
Рейтинг: 0 / 0
25.03.2009, 17:16
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891599
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467,

Вот теперь мне стало понятно ЧТО имеется ввиду. Коллега iscrafm - Мой Респект и благодарность за ссылочку. То есть вы рассматриваете контроль и управление качеством как отдельный проект. И за основу взяли ISO9001:2000 Мы на сегодняшний день используем TQM систему ISO 8402:1994 которая ещё глубже двигает зависимость PROCESSES, PEOPLE и REQUIREMENTS. Но я ни коим образом не буду Вас отговаривать от избранной схемы. Это уже огромный на мой взгляд скачёк в плане качества.

Только вот он является (обычно) решающим в завершающей стадии итерации проекта. Против TQM - это постоянное отслеживание ошибок и улучшения процессов.
...
Рейтинг: 0 / 0
25.03.2009, 17:32
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891682
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Mr MarmeladКоллега, Отдел Технического Контроля - это одна из наиважнейших частей нашей работы. Вот в этой ветке я попытался обозначить как работает такая команда. Кстати и вот этот пост нашего топика подчёркивает необходимость QA. Когда упоминается шаг "Отдать Тестерам" - значит не вернуть его в команду а показать "представителю заказчика" которым и является QA на время выполнения проекта.
Я не хотел показать отсутствие тестера. Моя цель была показать, что роли не удаляются, а совмещаются. Именно вот эта фраза
" ...Другой случай допустим - новую колоночку надо ввести во все ресурсы Например дату изменения значения в записи. - там заправлять будут Проектировщики баз и архитекторы, код будет выдан [всем]... " мне кажется указывает на удаление роли аналитика и распределение обязанностей среди непонятно кого. В случае победы зам аналитика сразу найдется, а вот неудачу придется раскидывать по всей команде.

Теперь про ссылки: да, именно это одна из граней основ. А именно там меня интересовало представление процесса. Так сказать просто рисунок, где представлены не только вход, тело, выход, а еще и упр.воздействие и ресурсы.
А вот сама схема ведения проектов все таки больше интересна на стыке ISO9000 и ITIL. К сожалению ISO8402 я не смотрел (нудные эти все стандарты), но обязательно на досуге посмотрю что-нибудь на русском языке. Вполне вероятно там кроется еще масса решений.
...
Рейтинг: 0 / 0
25.03.2009, 17:52
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35891755
Фотография Mr Marmelad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mr Marmelad
Участник
Enot5467 мне кажется указывает на удаление роли аналитика и распределение обязанностей среди непонятно кого. .

В Этом случае - опять же гипотетическом - аналитик может выступать заказчиком. Именно он определил ( сообразил из разговора с заказчиком) что системе надобен какой нить аудит - например время (ну и принадлежность канешна) изменения записи в [системных кодировочных] таблицах. На митинге он выдал мысль. Подключил Проектировщиков - ведь они именно имеют в хозяйстве все модели и условия баз данных. Те сказали чта им надо ещё и архитектора - как будут системы (UNIX, IBM, Windows) себя чувствовать во время таких перемен, посидели - нашли все таблички - а их мога быть штук .н..ста. Отметили в модельках - сгенерили скрипты, Архитект глянул - вроде будет работать, позвал DBA - те подкрутили и одним махом на все 125 баз данных - ГОТОВО. Опять же тестеровщика - на полный цикл Смок Тест, Регрешн Тест, Фанкшн Тест, Деплоймент Тест ну и что там у них ещё - по многу раз - пока не отладят всё - Ведь мы же знаем что баги всё равно будут. Не бывает без багов. То IP в системе не тот (архитектор блин - почему гад не апдейтал) То скрипт завис на таблице в 200000000 рекордов - уппс - не ожидали такого (DBA - крути). То таблицу не узнаёт Было VendorCode а теперь VendorSystemCode - ox уж эти Проектировщики - скока можна напоминать PowerDesigner не для картинок разработан... Ну и так далее... Всё это находят QA - возвращают в доработку и следят чтобы всё было задокументировано.
...
Рейтинг: 0 / 0
25.03.2009, 18:16
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35892256
Nemax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nemax
Гость
Могу предложить только пример ИТ-Стратегии бизнес -приложений.
http://tools4cio.ru/index.php/downloads?dl_cat=5
...
Рейтинг: 0 / 0
25.03.2009, 22:50
| Ответить | Цитировать | Написать  
Пример проектирования ИС
    #35906491
Enot5467
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Enot5467
Гость
Nemax,

интересно
...
Рейтинг: 0 / 0
01.04.2009, 17:41
| Ответить | Цитировать | Написать  
75 сообщений из 75, показаны все 3 страниц
  все  
Форумы / Разработка информационных систем [игнор отключен] [закрыт для гостей] / Пример проектирования ИС
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=33&tid=1548572]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 46ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 107ms
get tp. blocked users:
 1ms
others: 294ms
total:  488ms
созд. / загр.: 488ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]