В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 79
Текст из файла (страница 79)
Доступны черезhttp://java.sun.com/j2ee/5.0/index.jsp.[2] Web-сайт проекта Apache Struts http://struts.apache.org/.[3] C. Cavaness. Programming Jakarta Struts. O’Reilly, 2002.[4] Java Server Faces Specification, version 1.2. Доступна наhttp://java.sun.com/j2ee/javaserverfaces/download.html.[5] H. Bergsten. JavaServer Faces. O’Reilly, 2004.[6] Спецификации J2EE 5.0. Доступны через http://java.sun.com/javaee/5/javatech.html.[7] Web-сайт проекта Hibernate http://www.hibernate.org/.[8] C. Bauer, G.
King. Hibernate in Action. Manning, 2004.[9] B. A. Tate, J. Gehtland. Better, Faster, Lighter Java. O’Reilly, 2004.[10] Web-сайт технологии JDO http://jdocentral.com/.[11] D. Jordan, C. Russell. Java Data Objects. O’Reilly, 2003.[12] Спецификации Enterprise Java Beans 3.0. Доступны черезhttp://java.sun.com/products/ejb/docs.html.[13] Web-сайт проекта Spring http://www.springframework.org/.[14] R. Johnson. Expert One-on-One J2EE Design and Development.
Wrox, 2002.[15] R. Johnson, J. Hoeller, A. Arendsen, T. Risberg, C. Sampaleanu. Professional Java Developmentwith the Spring Framework. Wiley, 2005.[16] http://developer.mozilla.org/en/docs/Category:AJAX:Articles.[17] D. Crane, E. Pascarello, D. James. Ajax in Action. Manning, 2005.[18] G.
Alonso, F. Casati, H. Kuno, V. Machiraju. Web Services. Concepts, Architectures andApplications. Springer-Verlag, 2004.Сайт этой книги http://www.inf.ethz.ch/personal/alonso/WebServicesBook.[19] Сайт IBM, посвященный Web-службам и SOA. http://www128.ibm.com/developerworks/webservices/.[20] Э. Ньюкомер. Веб-сервисы. Для профессионалов. СПб.: Питер, 2003.[21] Х. Дейтел, П. Дейтел, С. Сантри. Технологии программирования на Java 2. Книга 3:Корпоративные системы, сервлеты, JSP, Web-сервисы.
М.: Бином, 2003.[22] А. Феррара, М. Мак-Дональд. Программирование web-сервисов для .NET. СПб.: ПитерBHV, 2003.[23] Спецификации WSDL 1.1 http://www.w3.org/TR/wsdl.[24] Спецификации SOAP 1.2 http://www.w3.org/TR/soap/.[25] Web-сайт стандарта OASIS UDDI http://www.uddi.org/.[26] Спецификации WS-Coordination, WS-Transactions и WS-BusinessActivity. Доступны черезhttp://www-128.ibm.com/developerworks/library/specification/ws-tx/.[27] Спецификации BPEL.
Доступны через http://www128.ibm.com/developerworks/library/specification/ws-bpel/.283[28] Спецификации WS-Reliability. http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsrm.[29] Спецификации WS-Security. http://www-128.ibm.com/developerworks/webservices/library/wssecure/.284Лекция 16. Управление разработкой ПОАннотацияРассматриваются основные деятельности, входящие в компетенцию руководителей проектов.
Вобщем рассказе о некоторых аспектах управления ресурсами, персоналом, рисками икоммуникациями проекта выделены особенности управления проектами по созданию ПО.Ключевые словаОрганизационная культура, структура организации, заинтересованные лица, спонсор, менеджер,заказчик, пользователь, команда проекта, цели проекта, содержание проекта, ресурсы,иерархическая структура работ, метрики сложности ПО, COCOMO II, сетевая диаграмма, PERTдиаграмма, диаграмма Ганта, критический путь, мотивация персонала, сплоченная команда,управление рисками, разрешение конфликтов, ведение переговоров.Текст лекцииЗадачи управления проектамиЭта лекция посвящена управлению проектами по разработке, поддержке или модификациипрограммного обеспечения. С достаточно общих позиций можно считать задачей управленияпроектами эффективное использование ресурсов для достижения нужных результатов.
Всегданужно получить как можно более хорошие результаты, используя при этом как можно меньшересурсов. При этом в первую очередь возникают два вопроса: что именно считается «хорошим»результатом проекта и чем, какими ресурсами, можно пользоваться для его достижения.Чтобы ответить на вопрос о том, какими критериями руководствуются при оценке проектов, ичего нужно добиваться, надо рассмотреть его с разных аспектов.Одним из самых важных критериев является экономическая эффективность проекта, т.е.отношение суммы доходов разного рода, полученных в его результате, ко всем затраченнымресурсам.
К сожалению, эти доходы чаще всего невозможно определить заранее. Поэтому приоценках проекта вместо дохода от его результатов рассматривают качество создаваемого ПО вовсех его аспектах, т.е. набор имеющихся функций, надежность работы, производительность,удобство для всех категорий пользователей, а также удобство расширения и внесения изменений.Характеристики качества должно соотноситься с требованиями рынка или заказчика и с ужеимеющимися продуктами.С более общих позиций и экономические, и неэкономические показатели результативностипроекта объединяют в понятие ценностей, создаваемых в его ходе.
Эти ценности могут иметьразличную природу в зависимости от проекта, от организации, в рамках которой он проводится, отнационально-культурных особенностей рынка и персонала и пр. Кроме того, ценностивыстраиваются в иерархию в зависимости от уровней рассмотрения проектов.• В одном конкретном проекте основной ценностью может быть достижениезапланированного качества результатов в указанный срок и в рамках определенногобюджета.В то же время, могут быть получены и другие ценности: достигнута высокая сплоченностькоманды; новые члены коллектива приобретут серьезные знания и полезные навыки;команда овладеет новыми технологиями; ее члены получат повышение и/или поощрения,которые повысят их лояльность компании и т.п.• На уровне нескольких зависящих друг от друга проектов (такую группу проектов называютпрограммой), в ходе которых создаются и дорабатываются несколько продуктов на единойплатформе, а также могут оказываться различные услуги, связанные с этими продуктами,ценности связаны, прежде всего, с качеством общей архитектуры создаваемых продуктов.В одном проекте работа иногда ведется по принципу «сдали-и-забыли», т.е.
основныеусилия направлены на то, чтобы заказчик подписал акт приемки работ или его аналог,после чего поставщик перестает отвечать за результаты, поэтому часто такой аспект285качества ПО, как удобство внесения изменений, игнорируется. Однако для бизнесаорганизации в целом проведение таких проектов небезопасно. Среди исследователей иэкспертов-практиков преобладает взгляд на любую программную систему как на системуразвивающуюся, полезность которой значительно снижается, если нет возможностирасширять ее, тем более — исправлять серьезные ошибки, которые всегда есть в сложныхпрограммах. Заказчик всегда сталкивается с проблемами поддержки ПО и рано или поздностолкнется и с необходимостью его развития.
На уровне группы проектов игнорированиеудобства модификации ПО, а также вопросов, связанных с организационными иэкономическими последствиями изменений в общей архитектуре, просто губительно.• На уровне организации в целом или подразделения, в рамках которого можетодновременно проводиться много проектов, связанных по предметной области,используемым технологиям и просто по вовлеченным в них людям, возникают другиеценности.
Это может быть отлаженность производственных процессов, высокаятехнологическая экспертиза и технологическое лидерство в своей области, низкая текучкакадров, повышение оборота, прибыли, капитализации, доли продаж в рамках отрасли,занимаемого среди поставщиков такой же продукции места по экономическим итехнологическим показателям.Поскольку каждый проект проводится в рамках какой-то организации, то принятая в нейсистема ценностей влияет и на оценку каждого конкретного проекта (см.
далее).Основные виды ресурсов, используемых в любом проекте, следующие.• Время.Этот ресурс всегда жестко ограничен. Продолжительность проекта фиксирована, это одноиз главных отличий проектов от обычной операционной деятельности, которой нужнозаниматься неопределенной время. Чаще всего эти ограничения определяются интересамизаказчика, выраженными в контракте, или решением руководства, основанном на анализерынка и информации о действиях конкурентов.Более того, даже при попытке создать «вялотекущий» проект без четкой установки еговременных рамок (иногда при помощи такого приема руководство организации пытаетсявыполнить нужные внутренние работы, не выделяя на них достаточных ресурсов),руководитель проекта должен настаивать на их определении.
Иначе проекта как таковогопросто не получится — эффективное использование времени играет очень важную роль вуспешности достижения необходимых результатов.• Бюджет.Бюджет проекта тоже всегда ограничен — деньги, как известно, лишними не бывают.Деньги часто рассматриваются как практически универсальный эквивалент другихресурсов: за счет вложения дополнительных денег пытаются выиграть во времени,привлечь дополнительный персонал и пр. Однако полностью в деньги можно перевеститолько используемое оборудование и материалы, да и то с некоторыми потерями вовремени на их приобретение и подготовку к работе.Вместе со временем бюджет задает основные ограничения на содержание и возможныерезультаты проекта.• Персонал.Персонал иногда рассматривается как возобновляемый ресурс, имеющий денежныйэквивалент («наймем проектировщика за 1500 у.е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
