Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Нельзя автоматизировать хаос




Выбор аппаратной платформы КИС

 

После того, как решение о выборе прикладного ПО на базе которого будет построена ИС принято, необходимо приянть решение об аппаратной платформе. Аппаратную платформу следует выбирать проанализировав и определив перспективы развития предприятия, принимая во внимание масштаб выбранного ПО и то, планируется ли его наращивание в будущем, а также всевозможные количественные и качественные параметры, такие как количество автоматизированных рабочих мест, их функции, объемы информации, направленность ее потоков. Масштабы и мощность системы определяют уровень технического решения.

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

Прежде чем говорить о том, как управлять проектами, определимся сначала, что собственно подразумевается под термином “проект”. Авторитетная в области управления проектами, признанной специальной дисциплиной управления, организация Project Management Institute определяет проект как “совокупность действий (процессов), приносящих результат, во время которых людские, финансовые и материальные ресурсы определенным образом организуются с тем, чтобы результат соответствовал утвержденным спецификациям, стоимостным и временным затратам как по качественным, так и по количественным показателям”.

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

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

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

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

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

Для справки отметим, что по статистике в мире всего 5% из всех проектов завершаются вовремя и не выходят за рамки бюджета, в то время как 80% - опаздывают или выполняются благодаря дополнительным инвестициям, а оставшиеся 15% - так и остаются незаконченными. Но также надо отметить, что надо стремится попасть в заветные пять процентов, а не использовать эту справку для оправдания перед руководством.

Качество является основным критерием выпускаемого программного продукта, оно ставит обязательным условием участие в разработке исключительно профессионалов и организацию процесса управления качеством продукта, однако третий критерий, бюджет, подвергается серьезному испытанию - возможность при создании информационной системы ограничить его за счет привлечения низкооплачиваемой рабочей силы отпадает.

Грамотное управление подразумевает увеличение производительности труда, но с обязательным сохранением, а в идеале и улучшением качества выпускаемых систем. В свою очередь, улучшение качества, согласно аналитику из специальной группы ISSIG Project Management Institute Эдварду Демингу (Edwards Deming), всегда связано с соответствующим увеличением производительности.

Основная сложность разработки инфосистем состоит в том, что создаются уникальные интеллектуальные решения. Консультант ISSIG Луис Зеллс (Lois Zells) считает, что “в 9 случаях из 10 специалисты в области информационных систем работают над задачами, которые до этого ни они сами, ни кто-либо другой не выполняли. В отличие от каменщиков, десятилетиями кладущих одни и те же кирпичи одним и тем же способом, программисты не пишут одинакового кода”. Хотя концептуально это правильно, необходимо рассмотреть факторы, которые могут помочь, грубо говоря, привести работу программиста к работе каменщика.

 




Поделиться с друзьями:


Дата добавления: 2014-12-10; Просмотров: 319; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.01 сек.