|
|
Знаете ли Вы, что ... | |
...инструкция по установке аватара описана в Правилах форума. | |
<< Предыдущий совет - Случайный совет - Следующий совет >> |
Интернет и общество Новые технологии в жизни общества, вопросы взаимодействия |
Ответить |
|
Опции темы | Опции просмотра |
29.01.2009 02:13 | #13 | |||
MChJ "Fido-Biznes"
Руководитель отдела
Сообщений: 20
+ 3
6/6
– 0
0/0
|
Цитата:
IMHO, данный подход ошибочен и обречен на неуспех в проектах по разработке и внедрению информационных систем. Такой подход (называемый каскадным подходом или "водопадом") в современных реалиях приведет к огромному увеличению стоимости проекта и к увеличению сроков ввода в промышленную эксплуатацию. Кроме того, ни один вменяемый заказчик, если ему дороги его деньги и время, не пойдет на такие жесткие условия - после утверждения технического задания ничего нельзя изменить до ввода в опытную эксплуатацию; ну а потом можно, но только за дополнительную плату. Данный подход (с некоторыми оговорками) применим при внедрении готовых решений при наличии грамотных специалистов, как со стороны исполнителя, так и со стороны заказчика. Примитивный, грубый пример. На шаге 2 Заказчик или разработчик увидел неточность в описании требований к реализации какой-либо функции. При описанном подходе предлагается неправильно реализовать данную функцию и сдать проект в опытную эксплуатацию. То есть сначала согласно утвержденному техническому заданию закончить разработку (потратить деньги, несмотря на обнаруженную ошибку). И только после сдачи проекта в опытную эксплуатацию заключать дополнительное соглашение на внесение изменений за дополнительное вознаграждение. Благо, если эта функция будет одна, и от нее не будут зависеть другие функции. А в случае, если от этой функции будут зависеть другие, то и в них придется вносить изменения за дополнительные деньги и тратить дополнительное время. Даже несовершенный в современных реалиях стандарт ГОСТ34.602-809 (Техническое задание на создание АС) допускает изменения к ТЗ на стадии разработки и запрещает изменения на стадии приема-сдачи. Цитата:
|
|||
|
Ответить |
29.01.2009 02:37 | #14 | ||
|
Цитата:
Цитата:
Существуют входные качественные и количественные параметры, а именно: 1. Нормативная база (Законодательство, должностные инструкции и прочая прочая прочая) - это кстати может меняться в процессе формирования ТЗ и до его утверждения... скажем - в целях оптимизации... согласны? 2. Персонал и материально техническое обеспечение - тоже может менятся в процессе формирования ТЗ и до его утверждения... скажем в целях соотвествия техническим требованиям к предполагаемой системе. 3. Кваллификация персонала - точно будет менятся (кто в здравом уме покупает бибику если на ней некому ездить?) Если на этом этапе все сделано и удовлетворяет требованиям Заказчика к проектируемой системе (то есть полностью отвечает его ожиданиям и удовлетворяет его потребностям) то о каком изменении может идти чем речь? Последний раз редактировалось Erkin Kuchkarov; 29.01.2009 в 02:49. |
||
|
Ответить |
Реклама и уведомления | |
29.01.2009 09:55 | #15 | |
Sharifa
ру-ль отдела ПО
Сообщений: 4,211
+ 2,224
2,971/1,351
– 51
57/54
|
Цитата:
|
|
|
Ответить |
29.01.2009 11:42 | #16 | |
Read Only
"СайТ За еду" Ltd
Сторож еды
Сообщений: 6,092
+ 5,084
5,502/2,454
– 113
149/96
|
Цитата:
|
|
|
Ответить |
29.01.2009 12:17 | #17 |
Nihol
тех. специалист
Сообщений: 16
+ 0
2/2
– 0
0/0
|
Всем привет!
Однажды я прочитал эту книгу....долго думал! Рекомендую всем, кто до сих пор не знаком с этой книгой и кто интересуется как "выживать в заведомо безнадежных проектах", кроме того там разбираются типичные причины, почему проекты бывают провальными. |
|
Ответить |
29.01.2009 12:28 | #18 | |
|
Цитата:
С другой стороны ТЗ составляется вместе с исполнителем, так что ошибки в ТЗ - проблема обоих сторон. Исполнитель виноват деже больше Заказчика, так как именно Исполнитель должен был всесторонее изучить потребности - это проблема в граждансом кодексе звучит как действие под аФфектом и в принципе Заказчик (если подумать и "правильно" посудиться) может объявить договор не действительным по причине именно такого "аффекта"... короче проект может развалиться от одного дурняка, возможно и незначительного и ваша категоричность ту не уместна.
__________________
Тот факт, что медуза выжила 650 миллионов лет без мозгов, даёт надежду многим. Последний раз редактировалось Nadir Zaitov; 29.01.2009 в 12:32. |
|
|
Ответить |
29.01.2009 12:49 | #19 | |
|
Цитата:
процессу формирования ТЗ и принимать в этом процессе активное участие. Вот на этапе формирования, согласования и утверждения Заказчик может затребовать от проектируемой АС все, что его душа пожелает. Тут как раз и выявляются слабые или сильные стороны того или иного решения и собственно подбор этого решения в умах аналитиков. Наше же, пректных манагеров, дело - тупо написать то самое ТЗ исходя из сформированых требований как заказчика так и аналитика. |
|
|
Ответить |
"+" от:
|
29.01.2009 13:00 | #20 | |
|
Цитата:
1. ТЗ на ИТ инфраструктуру для СУБД.. в ТЗ порешили что сервак, к примеру, имеет большую, достаточную, дисковую подсистему (DAS) Много памяти, много процессоров. 4 езернет контроллера, RAID офигенный, ОС Windows 2003 R2 Std, СУБД SQL 2005 Std. (ИОПсы, террафлопы - все подсчитали по какой нить формуле или взяли из сайзера производителя... не в этом дело). Зашибись? Подписали. 3. Процесс закупки и доставки прошел как нельзя лучше - железку отгрузили, расстаможили, собрали... тут и лицензии подошли (конвертик) 2. В процессе интеграции и миграции у заказчика появились\сформировались новые требования - нужен отказоустойчивый кластер. Заказчик согласен пересмотреть условия ТЗ. Готов подписать допу без увеличения стоимости - буквально слезно просит бамажку. Ну и как Вы, интегратор, поступите? |
|
|
Ответить |
|