Управление разработками ИС.pptx
- Количество слайдов: 101
УПРАВЛЕНИЕ РАЗРАБОТКАМИ ИС
Управление разработкой • Управление созданием ИС, как правило, рассматривают в двух аспектах: организационном и функциональном. • В организационном аспекте управление разработкой рассматривается по уровням организационноадминистративной структуры с соответствующими правами и обязанностями субъектов проектной организации. • В функциональном аспекте управление разработками рассматривается как применение соответствующих методов и средств организации и ведения проектных работ.
Элементы процесса управления • Субъект управления проектом(организация); • Пользователь; • Заказчик; • Администратор; • Разработчик
Субъект управления проектированием ЭИС • Выделение субъекта управления связано с разделением труда в • • • группе специалистов в процессе разработок ЭИС. Управление работами в этом случае может осуществляться на нескольких уровнях: - руководства организации; - руководства обеспечивающих подразделений (например, плановопроизводственного отдела и т. п. ); - руководства функциональными подразделениями; - руководителей проектов (главных конструкторов); - руководителей проектных групп (ответственных исполнителей). Организация работ по проектированию и разработке ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором и разработчиком
Пользователь • организация или группа подразделений, которые используют результаты обработки информации на ЭВМ. Для ЭИС под пользователем понимают, прежде всего, административноуправленческий аппарат, для которого создается эта система. • Пользователь выполняет следующие функции: - формирует исходные данные для проектирования и обработки, - определяет состав задач для автоматизации, - определяет основные требования к задачам и режим функционирования системы.
Заказчик • ответственное лицо, под которым понимается организация или подразделение и которое выполняет функции: - формирует требования к системе и ее частям, - выдает техническое задание, финансирует разработку ЭИС, - обеспечивает проведение комплекса мероприятий по ее созданию, - проводит внедрение и прием ЭИС. • заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, за сроки создания системы, правильность использования ресурсов в процессе проектирования.
Администратор • ответственное лицо, которое выполняет эксплуатацию программно-технических средств и информационного и методологического обеспечения ЭИС (технологические и инструкционные карты), • Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком за соблюдением условий эксплуатации, требований к технической документации
Разработчик • ответственное лицо (подразделение , организация или группа организаций), которое выполняет следующие функции: - разрабатывает ЭИС по техническому заданию заказчика, - принимает участие во внедрении, - осуществляет сдачу проекта заказчику, - осуществляет авторское сопровождение проекта. • Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научнотехнический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных ресурсов.
Схемы организаций разработчиков Существует несколько типов схем организации работ с участием четырех сторон, выбор которых зависит от объема проектируемой системы.
Схема организации при малом заказе • заказ имеет небольшие размеры по стоимости и по продолжительности работ, то в одном лице выступают заказчик, разработчик и администратор • К преимуществу данной схемы можно отнести минимальное количество организаций – участников процесса и минимальные сроки и стоимость разработки. • Однако совмещение в одной организации функций разрабатывающей стороны и принимающей стороны имеет ряд существенных недостатков: - отсутствует действенный контроль научно-технического уровня разработки, сроков выполнения работ; - не достигается высокого профессионального уровня разработчиков
Схема организации при небольшом заказе • * Пользователь Данные для проектирования Данные Для разработки Заказчик Разработчик Администратор Результаты обработки
Средний и большой заказ • • • Для средних и больших заказов применяют схему, согласно которой функции разработчика отделяются от функций заказчика и администратора и выполняются другой организацией преимущества схемы - рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС; - возникает возможность привлечения к разработке ЭИС специализированных организаций (НИИ, СКБ). недостатки: - отсутствие прямой связи между разработчиком и пользователем, что создает трудности в своевременном получении и детализации исходных данных для проектирования; - возникают определенные трудности приеме проекта в эксплуатацию из-за желания администраторов получить методологическое обеспечение задач, соответствующее идеальным условиям эксплуатации, что в свою очередь требует больших сроков и объемов по доработке проекта
Модель при большом и среднем заказах • * пользователь Заказчик администратор Проектная документация ТЗ, данные для проектирования и финансирования разработчик
Выполнение нескольких заказов • В том случае, если заказчик – большая организация, которая • • курирует разработку нескольких проектов ЭИС. В этом случае на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС. Преимуществами данной схемы являются: более высокая степень специализации работников, следовательно, более высокий профессиональный уровень; возможность организации контроля сроков и качества выполнения работ.
Схема организации при нескольких заказах
Консалтинг и аутсорсинг • При разработке больших и сложных систем фирмы (пред. схема) часто привлекают соисполнителей, для выполнения подрядных работ. • Консалтинг это консультации связанные с разработкой и сопровождением ЭИС. • Под аутсорсингом понимаются любые работы, проводимые силами внешних организаций, за исключением консультационных.
Консалтинг • Желание получить в том или ином секторе ИТ экспертную оценку ситуации (в самой компании или в целом по отрасли). • Часто встречаются ситуации, когда исследуется область разового интереса, и тогда обращение к консалтингу — единственный вариант. Как правило, однако, дело касается сферы постоянного интереса, в которой компания или не находит обязательным иметь собственных специалистов, или располагает несколькими сотрудниками, на чье мнение и квалификацию, однако, не считает возможным положиться при решении стратегических вопросов. • Чаще всего это следствие ситуации, когда организация либо в целом экономит на фонде зарплаты, либо, достаточно хорошо оплачивая специалистов профильного направления деятельности, недооценивает прямую взаимосвязь информационных технологий с эффективностью основного бизнеса и считает ИТ сугубо второстепенным направлением (с соответствующей корректировкой размера зарплаты).
типичная тематика консалтинговых услуг • разработка информационной модели системы. . . • определение комплекса функциональных требований к. . . • разработка сравнительных критериев выбора программных средств для. . .
Задачи консалтинговой фирмы • консалтинговая фирма должна выдать качественную оценку сложившейся ситуации и/или ряд рекомендаций, после чего заказчику остается только использовать ее выводы. Обычно перед консалтинговой фирмой стоят две параллельные задачи: • выработать заключения и рекомендации по всем рассматриваемым проблемам максимально объективно и квалифицированно • произвести хорошее впечатление на руководство заказчика, чтобы поддержать репутацию и в конечном счете обеспечить дальнейшие заказы в своей области;
Примеры недобросовестных советов • допустим, компания в течение длительного времени в указанном секторе ИТ шла в стратегически неверном направлении, инвестировала огромные средства в покупку неэффективного для ее целей ПО или техники, то ни одна консалтинговая фирма не рискнет изложить в прямом виде объективную (но горькую) истину: время и деньги были потрачены впустую, надо все создавать заново. Она просто не может позволить себе заявить то, что руководство заказчика подсознательно не желает слышать. Резко негативные результаты исследования уважаются в научном мире, но совершенно не пользуются популярностью в коммерческом. Значит, будут высказаны, вообще говоря, верные замечания об имеющихся “отдельных недостатках” (именно как о недостатках, даже если их скорее можно назвать провалами) и предложены рекомендации по “косметическому ремонту” ситуации, т. е. меры, до некоторой степени облегчающие положение, но по большому счету просто затягивающие стагнацию перед неизбежным технологическим тупиком.
Примеры недобросовестных консультаций • Пусть цель консалтингового исследования является сравнительный обзор рынка программных средств определенного назначения, с тем чтобы заказчик смог выбрать наилучший в его условиях программный пакет для внедрения. При этом, допустим, среди рассматриваемого десятка производителей ПО есть один, давно находящийся с консалтинговой фирмой в особо дружественных отношениях, тогда с высокой степенью вероятности можно ожидать, что будут выгодно подчеркнуты те аспекты, по которым “нужный” программный пакет выигрывает, и окажутся в тени аспекты, по которым он проигрывает остальным.
Привлечение соисполнителей (аутсорсинг) • Если заказ очень большой и сложный , то проектирующая организация может привлекать к своей работе организации – соисполнителей разных уровней иерархии, что в свою очередь позволяет использовать труд специализированных и боле профессиональных организаций. Сама же выступает в качестве головной, координирующей деятельность остальных.
Схема при аутсорсинге
Проблемы аутсорсинга • целесообразно и выгодно применять аутсорсинг тогда, когда речь идет о работах разовых или эпизодических. Там же, где работа имеет постоянный, жизненно важный для предприятия с технологической точки зрения, характер гораздо выгоднее и эффективнее держать от одного до нескольких высококвалифицированных специалистов. Отказ от найма высокооплачиваемых ключевых специалистов и ориентация на тотальный аутсорсинг по сложным видам работ означает реализацию известной поговорки “скупой платит дважды, кроме того при любом аутсорсинге используются во всех смыслах чужие сотрудники, которые прямо не подчиняются руководству компании-заказчика и никак не заинтересованы в ее конечных успехах. А такая позиция не может не влиять на эффективность их работы. Мотивация собственного специалиста, отдающего себе отчет, что его работа достойно оплачивается именно за высокую квалификацию, и связывающего свое будущее с компанией, неизмеримо выше
ТЕХНОЛОГИИ ОРГАНИЗАЦИИ И УПРАВЛЕНИЯ РАЗРАБОТКАМИ ИС Тема 3
Форма управления • Форма управления является тем стержнем, который во многом определяет содержание и качество проекта системы. Можно передать в распоряжение разработчиков самые совершенные средства проектирования, четкие формы документации, планы работ, методы контроля, но без должной организации не получить проект, удовлетворяющий потребностям заказчика. И наоборот, совершенная форма организации проектирования восполняет недостаток эффективных средств проектирования и в отдельных случаях даже квалификации разработчиков • Формы управления, применяемые в организациях-разработчиках ЭИС, зависят от выполняемых работ. Как правило, в организациях разработчиках выполняются работы, связанные: - с проектированием ЭИС; - с поддержкой и сопровождением ЭИС. Существуют три формы: функциональная, проектная, матричная.
Функциональная форма управления • построения структуры организации используется при выполнении задач проектирования постоянного характера. Для выполнения каждого вида задач, например, разработки постановки экономических задач, информационного обеспечения и т. п. , формируются функциональные подразделения из специалистов определенного профиля. Подобная организационная структура обладает высокой степенью централизации управления, ей присущ авторитарный стиль руководства. В области разработки ЭИС функциональная структура организации встречается весьма редко.
Проектная форма • Для построения организационных структур проектных организаций наиболее часто используется. Для этого формируется организационное подразделение – проектная группа (проект), которая предназначена для одноразовой разработки ЭИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель (главный конструктор) который имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения проекта может быть расформирован.
Матричная форма управления • предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектные группы для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность). Матричные структуры применяются в условиях высокой степени кооперации функциональных подразделений. Эти структуры основаны на особом механизме взаимодействия функциональных и проектно-целевых подсистем аппарата управления проектной организацией.
Технологии управления разработкой ИС • Управление проектированием ЭИС в функциональном аспекте • • рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимаются действия и процедуры, связанные с решением конкретных задач или реализацией функций управления, к которым относятся: - процессы инициации - процессы планирования - процессы исполнения - процессы анализа - процессы оперативного управления или регулирования - процессы завершения
Расшифровка процессов • - процессы инициации, связанные с принятием решения о начале • • • выполнения проекта или какой либо очередного этапа или фазы его; - процессы планирования – это совокупность процедур, связанных с определением целей и критериев успеха проекта и разработкой рабочих схем их достижения; - процессы исполнения предназначены для координации людей и других ресурсов для выполнения плана - процессы анализа дают возможность определить соответствие плана и исполнения проекта поставленным целям и критериям успеха и принять решения о необходимости применения корректирующих воздействий; - процессы оперативного управления или регулирования – это совокупность процедур, предназначенных для определения необходимых корректирующих воздействий, их согласования, утверждения и применения; - процессы завершения – это процессы формализации выполнения проекта и составления отчетности.
Характеристики процессов • Процессы управления проектами накладываются друг на друга и происходят с разными интенсивностями на всех стадиях проекта. • Процессы управления проектами связаны между собой своими результатами – результат выполнения одного становится исходной информацией для другого. И, наконец, имеются взаимосвязи групп процессов различных фаз (этапов) проекта. Например, закрытие одной фазы может являться входом для инициации следующей фазы (пример: завершение фазы проектирования требует одобрения заказчиком проектной документации, которая необходима для начала реализации). В реальном проекте фазы могут не только предшествовать другу, но и накладываться. Внутри каждой группы процессы управления проектами связаны друг с другом через свои входы и выходы. • Вывод. Процессы управления составляют сложную иерархию.
Компоненты процессов • Входы – документы или документированные показатели, согласно которым процесс исполняется. • Выходы – документы или документированные показатели, являющиеся результатом процесса. • Методы и средства – механизмы, по которым вход преобразуется в выход.
Процессы планирования. • Планирование имеет большое значение для проекта и включает сравнительно много процессов. Некоторые из процессов планирования имеют четкие логические и информационные взаимосвязи и выполняются в одном порядке практически во всех проектах. Так, например, сначала следует определить из каких работ состоит проект, а уж затем рассчитывать сроки выполнения и стоимость проекта. Эти основные процессы выполняются по несколько раз на протяжении каждой фазы проекта.
Состав основных процессов планирования • • • Планирование целей Декомпозиция целей Определение состава операций Определение взаимосвязей операций Оценка длительностей или объемов работ Определение ресурсов Назначение ресурсов Оценка стоимости Составление расписания выполнения работ Оценка бюджета Разработка плана исполнения проекта Определение критериев успеха
Состав вспомогательных процессов планирования • Планирование качества • Планирование организации • Назначение персонала • Планирование взаимодействия • Идентификация риска • Оценка риска • Разработка методов реагирования • Планирование поставок • Подготовка условий
Содержание процессов планирования • Планирование целей – разработка постановки задачи (проектное • • обоснование, основные этапы и цели проекта). - Декомпозиция целей – декомпозиция этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля. - Определение состава операций (работ) проекта – составление перечня операций, из которых состоит выполнение различных этапов проекта. - Определение взаимосвязей операций – составление и документирование технологических взаимосвязей между операциями. - Оценка длительностей или объемов работ – оценка количества рабочих временных интервалов , либо объемов работ, необходимых для завершения отдельных операций
Содержание процессов планирования • Определение ресурсов (людей, оборудования, материалов) проекта • • • определение общего количества ресурсов всех видов, которые могут быть использованы на работах проекта и их характеристик. Назначение ресурсов – определение ресурсов, необходимых для выполнения отдельных операций проекта. Оценка стоимости – определение составляющих стоимости операций проекта и оценка этих составляющих для каждой операции, ресурса и назначения. Составление расписания выполнения работ – определение последовательности выполнения работ проекта, длительностей операций и распределения во времени потребностей в ресурсах и затрат, исходя и с учетом наложенных ограничений и взаимосвязей. Оценка бюджета – приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам). Разработка плана исполнения проекта – интеграция результатов остальных подпроцессов для составления полного документа. Определение критериев успеха – разработка критериев оценки исполнения проекта
Содержание вспомогательных процессов планирования • Планирование качества – определение того, какие стандарты качества • • использовать в проекте, и того, как эти стандарты достичь. Планирование организации – определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации. Назначение персонала – назначение человеческих ресурсов на выполнение работ проекта Планирование взаимодействия – определение потоков информации и способов взаимодействия, необходимых для участников проекта. Идентификация риска – определение и документирование событий риска, которые могут повлиять на проект. Оценка риска – оценка вероятностей наступления событий риска, их характеристик и влияния на проект. Разработка методов реагирования – определение необходимых действий для предупреждения рисков и реакции на угрожающие события. Планирование поставок – определение того, что, как и когда должно быть поставлено. Подготовка условий – выработка требований к поставкам и определение потенциальных поставщиков.
Процессы исполнения и контроля. • Процессы исполнения и контроля. Под исполнением подразумеваются процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Регулярное измерение параметров проекта и идентификация возникающих отклонений далее также относится к процессам исполнения и именуется контролем исполнения. Контроль исполнения следует проводить по всем параметрам, входящим в план проекта
Состав процессов исполнения • • • К основным процессам исполнения можно отнести сам процесс исполнения плана проекта. Среди вспомогательных процессов можно отметить: учет исполнения – подготовка и распределение необходимой для участников проекта информации с требуемой периодичностью; подтверждение качества – регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества; подготовка предложений – сбор рекомендаций, отзывов, предложений, заявок выбор поставщиков – оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов; контроль контрактов – контроль исполнения контрактов поставщиками и подрядчиками; развитие команды проекта – повышение квалификации участников команды проекта. исполнения проекта.
Процессы анализа • Процессы анализа включают как анализ плана, так и анализ исполнения • Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана командой и другими участниками проекта. На стадии планирования результатом анализа плана может быть принятие решения о необходимости изменения начальных условий и составления новой версии плана, либо принятие разработанной версии в качестве базового плана проекта, который в дальнейшем служит основой для измерения исполнения. • Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования. Для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество и стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями
Основные процессы анализа • - анализ сроков – определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным; • - анализ стоимости – определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным; • - анализ качества – мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта; • - подтверждение целей – процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т. д. ).
Вспомогательные процессы • Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. • Эти процессы включают: • - оценку исполнения – анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта; • - анализ ресурсов – определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов, машинного времени и т. д. плановым значениям.
Процессы оперативного управления • Управление исполнением проекта – это определение и применение • • необходимых управляющих воздействий с целью успешной реализации проекта. Если исполнение проекта происходит в соответствии с намеченным планом, то управление фактически сводится к исполнению – доведению до участников проекта плановых заданий и контролю их реализации. В том случае, если в процессе реализации возникли отклонения, анализ которых показал, что необходимо определение и применение корректирующих воздействий, тогда требуется - найти оптимальные корректирующие воздействия, - скорректировать план оставшихся работ, - согласовать намеченные изменения со всеми участниками проекта.
основные процессы оперативного управления • К основным процессам оперативного управления, • • встречающимся практически в каждом проекте, относятся: - общее управление изменениями – определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту - управление ресурсами – внесение изменений в состав и назначения ресурсов на работы проекта - управление целями – корректировка целей проекта по результатам процессов анализа - управление качеством – разработка мероприятий по устранению причин неудовлетворительного исполнения.
вспомогательные процессы оперативного управления • - управление рисками – реагирование на события и изменение рисков в процессе исполнения проекта; • - управление контрактами координация работы (суб)подрядчиков, корректировка контрактов, разрешение конфликтов.
Процессы завершения • . - закрытие контрактов – завершение и закрытие контрактов, включая разрешение всех возникших споров; • - административное завершение – подготовка, сбор и распределение информации, необходимой для формального завершения проекта.
ТЕХНОЛОГИИ УПРАВЛЕНИЯ КАЧЕСТВОМ ИС
Понятие качества • Согласно подходу стандартов системы качества: качество - это совокупность характеристик объекта, имеющая отношение к его способности удовлетворить установленные и предполагаемые требования потребителя. При этом, что важно, под объектом качества может пониматься как собственно продукция (товары или услуги), процесс ее производства, так и производитель (организация, система или даже отдельный работник). • Что наиболее существенно для качества: чтобы произведенная продукция при тестировании удовлетворяла набору требований, чтобы она качественно производилась или чтобы каждый работник был обучен качественному производству
Стандарты качества. • История стандартов качества ИСО 9000 восходит к Британским стандартам BSI 5750, которые были одобрены Британским институтом стандартов (British Standard Institute - BSI) в 1979 году. В свою очередь эти стандарты часто считаются восходящими к американским военным стандартам MIL-Q 9858, принятым в конце 50 -х годов в США. Стандарты серии ИСО 9000 - это пакет документов по созданию систем качества и обеспечению качества, подготовленный членами международной организации, известной как "ИСО/Технический Комитет 176" (ISO/TC 176). Ныне стандарт BSI 5750 известен как стандарт ИСО 9000 версии 1987 года.
Стандарты качества. • все международные стандарты с номерами ИСО 9000 - 9004, в том числе все разделы (которые могут модифицироваться отдельно) стандарта ИСО 9000 и стандарта ИСО 9004; • все международные стандарты с номерами ИСО 10001 - 10020, в том числе все их разделы; • ИСО 8402 и в отдельных случаях - некоторые другие стандарты, определяющие специфическую деятельность поставщика. • Три стандарта из серии ИСО 9000 (ИСО 9001, ИСО 9002 и ИСО 9003) являются фундаментальными документами Системы Качества, определяют методологию обеспечения качества и представляют собой три различные модели функциональных или организационных взаимоотношений между участниками системы качества (как правило "поставщик", "потребитель", "субконтрактор" или "субпоставщик").
Руководства можно разделить по направлениям: • Подготовка руководства по качеству (Quality manual) и другой документации - ISO 10013 ("Руководящие указания по разработке руководств по качеству") и ISO 10016. • Подготовка персонала и управления, проектирование - ISO 1005, ISO 1006, ISO 1007, ISO 10014, ISO 10015. • Руководящие и специфические требования: ISO 40001, ISO 40002, ISO 13485 и другие и соответственно ГОСТ Р 40. 001 -96, ГОСТ Р 40. 002 -96, ГОСТ Р 40. 003 -96, ГОСТ Р 40. 004 -96, ГОСТ Р 40. 005 -96 и другие. • Получившая система стандартов (точнее ее подмножество - 90019003) обладает определенной вложенностью, то есть каждый последующий стандарт определяет систему качества для более узкой области нежели предыдущей. Стандарты 9000 и 9004 определяю общие требования к системе качества и модели управления качеством.
Структура стандартов
Качество по Стандарту ИСО-9126 • Функциональность • Надежность • Пригодность к использованию • Эффективность • Переносимость • Сопровождаемость
Качество по Стандарту ИСО-9126 • Функциональность Соответствие назначению Точность Способность взаимодействовать со средой Соответствие нормам Безопасность (защита от взлома данных и других преступных посягательств) • Надежность Зрелость ("обкатанность") Отказоустойчивость Способность восстанавливаться после сбоев • Пригодность к использованию Понимаемость Изучаемость Удобство и простота в работе
Качество по Стандарту ИСО-9126 • Эффективность Быстродействие и время отклика Потребление ресурсов • Сопровождаемость Анализируемость (диагностика причин ошибок и сопоставление с исходным кодом) Пригодность к изменениям Стабильность Тестируемость • Переносимость Адаптируемость Легкость инсталляции Соответствие нормам по переносимости и инсталляции Заменяемость (способность заменить аналоги? )
Процесс сертификации. • Для того, чтобы получить свидетельство о соответствии системы качества стандартам ИСО 9000, необходимо пройти процесс сертификации. • Так как сертификацию проходит система качества, то она должна быть предварительно создана на предприятии. В принципе предприятие может создать систему качества совершенно самостоятельно, не прибегая к помощи консультантов. Однако если предприятие не имеет опыта в такой деятельности, то полезно бывает пригласить специалиста уже на этом этапе, что позволит в будущем сократить количество сертификационных аудитов. . • Далее с помощью внешнего аудита качества предприятие должно удостовериться, что созданная система качества соответствует требованиям ИСО 9000 и, если это произошло, то она получает соответствующий сертификат. Обычно с первого раза пройти аудит не удается, так как в его ходе выявляются недостатки системы качества. На их устранение выделяется некоторое время, после которого аудит повторяется. Такой процесс считается нормальным и закладывается в проект сертификации. Проект сертификации является плодом совместной деятельности регистратора (специализированной компании, имеющей право проводить сертификацию) и компании-претендента. Обычно с 3 -4 попытки сертификация проходит
Регистраторы в России • Bureau Veritas • BSI (British standard Institute) • Lloyd Register • TUV в лице TUV-Интерсертифика
Стоимость сертификации включает • стоимость создания системы качества • стоимость услуг по аудиту и фиксированная плата за сертификацию • стоимость поддержания системы качества в актуальном состоянии и стоимость периодического аудита
Программное обеспечение и система качества. • В системах качества о программных продуктах говорят в случаях: • собственно поддержание системы качества (системы документооборота) • поддержание качества процессов управления • поддержание качества технологических процессов.
Требование ИСО 9000 • Так как основное требование ИСО 9000 - это документированность процессов, то для поддержания документации и доведения ее до заинтересованных лиц, необходим как минимум текстовый редактор и система электронной почты. Лучше если конечно есть хоть какая-нибудь система документооборота, например MS Outlook и IBM Lotus Notes и Novel Group. Wize • Если применено какое-нибудь средство автоматизации процессов управления (например ERP система соответствующего класса), то острота данной проблемы может быть несколько или совсем снята, так как такие системы по меньшей мере поддерживают так называемое "управление техническими изменениями" (engineering change order), что часто бывает достаточно для реализации внутреннего документооборота, связанного с изменениями продукции и технологии. • Если имеется необходимость в системе качества описания бизнеспроцессов с помощью программных средств, то целесообразно использовать MS Visio
Total Quality Management. • В настоящее время достигнуто понимание того, что стандарты серии ИСО 9000 обеспечив построение Системы качества на предприятии, не могут однако обеспечить во-первых ее совершенствование, во-вторых удовлетворенность конечного потребителя, что является основным для рыночно ориентированной экономики. Для того, чтобы разрешить возникающие противоречия и создать всеобъемлющую концепцию качества как системы удовлетворения потребителя и разрабатываются концепции системы всеобщего управления качеством -TQM (Total Quality Management). Предполагается, что все новые стандарты управления качеством будут строиться на основании именно этой концепции
Базовые элементы. TQM. • • • Вовлеченность высшего руководства Вовлеченность покупателя Разработка продуктов для качества Разработка производственных процессов исходя из требований качества. Контроль производственных процессов для достижения качества Развитие партнерских отношений с поставщиками Послепродажное обслуживание и после-производственный сервис. Вовлеченность работников в процесс управления качеством. Тестирование и стремление к постоянному улучшению, на основе достигнутых результатов.
Вовлеченность высшего руководства. • Смысл данного требования состоит в том, что весь руководящий состав компании, включая высшее руководство должен быть вовлечен и участвовать в процессе повышения качества, начиная от начальных этапов создания бизнеса и формирования стратегических целей, до конкретных тактических решений, которые могут существенно повлиять на общее управление качеством. Одна из главных задач вовлеченного руководства - это необходимость учета требований качества на самых ранних этапах создания, модернизации бизнеса и не такая уже тактическая задача, как может показаться - это необходимость постоянного стимулирования работников к достижению высших стандартов качества продукции.
Вовлеченность покупателя. • Во многих случаях источником информации о нарушении качества является покупатель. Его важнейшая роль в системе управления качеством сказывается в своевременном доведении до поставщика информации о нарушении качества, так и во включенности в процесс создания высококачественного продукта. Покупатель, как источник потребностей должен сообщать о своих потребностях производителю. Но и производитель должен интересоваться этими потребностями, что в у нас часто отсутствует. Действительно, у нас продукция производилась не та, которая была нужна потребителю, а та которая была включена в план. Это противоречит одному из основных требований TQM которое требует чтобы продукция была нужна
Разработка производственных процессов • исходя из требований качества. Производственные процессы рассматриваются в стандарте ИС-9000. Одна из основных задач этих стандартов, как раз установление, разработка производственных процессов для производства качественной продукции. Как основное требование стандартов можно сформулировать то, что должны быть четко разделены неконтролируемые факторы и такие, как возможное неправильное функционирование машин, некачественные материалы, неправильное выполнение рабочими своих обязанностей. Такие контролируемые факторы могут быть устранены в процессе внедрения системы ИС-9000.
Тестирование и стремление к постоянному улучшению • Тестирование в данном случае имеется в виду, как тестирование по абсолютным показателям: проверка качества продукции и тестирование сравнимых образцов или рыночные тесты. Рыночные тесты это тестирование нескольких образцов разных производителей одинаковой продукции с целью выявления наиболее оптимальных решений и неформальный обмен опытом между конкурентами. Это широко практикуется в настоящее время и у нас, во всех разумно организованных производствах.
Стандарты АС и ПС • Стандарт ISO 12207: 1995. Автоматизированная система по ISO и ГОСТ • "По определению ISO 12207 - это базовый стандарт процессов жизненного цикла (ЖЦ) ПС, ориентированный на различные (любые!) виды ПС и типы проектов АС, куда ПС входит как часть. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПС, он охватывает ЖЦ ПС от концептуализации идей до завершения ЖЦ. • Стандарты фиксируют, что в понятие АС включены такие свойства/характеристики системы, как "потребности", "цели" и "люди", а также предполагают связь стандартов на АС и ПС.
Общие показатели качества и надежности ПС • "По ISO 9126: 1991: рекомендуется использовать 6 основных групп • • • характеристик качества ПС, детализируемых через 21 характеристику: функциональная пригодность (пригодность для применения, точность, защищенность, способность к взаимодействию, соответствие стандартам и правилам проектирования); надежность (уровень завершенности (отсутствия ошибок), устойчивость к ошибкам, перезапускаемость (повторновыполняемость)); применимость (понятность, изучаемость, простота использования); эффективность (ресурсная экономичность, временная экономичность); сопровождаемость (удобство для анализа, возможность модификации, стабильность, тестируемость); переносимость (адаптируемость, структурированность, замещаемость, внедряемость
Процессы и требования для обеспечения качества • "В ISO 12207 описаны 8 вспомогательных процессов, которые поддерживают реализацию какого-либо основного процесса (например, "создание ПС"), будучи неотъемлемой частью всего ЖЦ программного изделия, и обеспечивают должное качество проекта ПС. Это процессы: "решение проблем", "документирование", "управление конфигурацией", "гарантирование качества". Последний использует результаты остальных процессов группы обеспечения качества, в которую входят процессы: "верификация", "аттестация", "совместная оценка", "аудит".
требований к АС • предусматривается, что: • рассматривается область применения системы для определения требований системы (к системе); • спецификация требований системы должна описывать: функции и возможности системы, бизнес-требования, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования; • квалификация требований системы должна быть документирована.
Требование к качеству и надежности ПС • Для обеспечения качества и надежности ПС стандартами • • рекомендуется формулировать требования: к объекту разработки на данном этапе - к его программным и информационным компонентам, а также к интерфейсу между ними и с внешней средой; к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа; к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качество ПС; к методам и средствам контроля, измерения и документирования качества процессов и результатов выполненных работ.
Управление проектными рисками • Под риском в проектировании обычно понимают некоторое событие • • или обстоятельство, которое может негативно повлиять на реализацию проекта. Примеры: уволился ведущий специалист и, как следствие, потеряны результаты работы в его секторе ответственности (причина – отсутствие документации по выполняемым работам); утрачено большое количество документов компании из-за отказа жесткого диска на сервере хранилища данных (причина – руководство компании сочло затраты на резервное копирование данных ненужными); приобретенная система бухгалтерского учета оказалась неспособной адаптироваться к изменениям в законодательстве, и пришлось покупать новую (причина – не был проведен качественный анализ возможностей приобретаемой системы).
комментарий • Если проект терпит неудачу, обычными комментариями являются фразы типа: “Это чистая случайность!”, “До этого у нас все шло гладко”, “Кто же знал, что так произойдет? ” и т. п. Да, конечно, знать, что такое произойдет, вряд ли кто-то мог, но вот предусмотреть возможность возникновения проблемной ситуации и “нанести упреждающие удары”, повысить вероятность успеха проекта, любой компании вполне по силам практически всегда. Надо только знать, как это можно делать, затратив незначительные (по сравнению со стоимостью проекта) средства.
Процессы управления рисками • Управление проектными рисками, включает в себя четыре основных процесса: • идентификация, • анализ, • планирование • контроль рисков.
Идентификация рисков • это первая стадия процесса управления ими. На этом шаге выявляются и описываются риски, которые могут возникнуть при реализации проекта, а также взаимосвязи рисков между собой. Выявленные риски классифицируются по группам (например, могут быть определены следующие категории рисков: финансовые, технологические, политические, профессиональные, форс-мажор и т. д).
Анализ рисков • производится оценка рисков. Здесь подсчитываются вероятности рисков и ущерба, который они могут нанести, а также определяются границы рисков. После этого риски группируются по степени важности и выделяются наиболее важные из них, которые будут тщательно отслеживаться на протяжении всего срока ведения проекта.
Планирование рисков • разрабатываются мероприятия по предотвращению рисков и устранению их последствий, если они все же произойдут. Соответствующие документы включают в себя описание действий по реагированию на возникновение каждой из возможных проблем с учетом их влияния на другие составляющие проекта и перечень лиц, ответственных за осуществление соответствующих действий по их нейтрализации. К планированию привлекаются и непосредственные участники проекта, а само оно ведется с учетом текущего состояния проекта и наличия ресурсов для осуществления предложенного решения
Контроль рисков • является мониторинг выявленных рисков и осуществление планово-предупредительных мероприятий. На основании данных такого мониторинга происходит инициирование ответной реакции на проблемную ситуацию в случае выявления таковой. Правильно организованный контроль выполнения проекта обеспечивает руководство компании качественной и своевременной информацией для принятия решений по предотвращению рисков.
Выявление и описание рисков • Наиболее распространенными методами выявления рисков являются анкетирование и мозговой штурм. • При анкетировании обычно запрашивается информация о характеристиках каждого из потенциальных рисков и на основании анализа полученных ответов принимается решение о внесении соответствующих рисков в список для дальнейшего рассмотрения. Например, анализ ответа на вопрос: “Сколько сотрудников сменило место работы в информационном отделе компании? ” может показать необходимость обязательного учета риска текучести кадров. • Мозговой штурм является процессом, когда специалисты по предметной области вместе с экспертами по управлению рисками обсуждают возникновение возможных проблем. При этом в процессе мозгового штурма его участниками, как правило, предлагается огромное число потенциальных рисков. • Все выявленные риски описываются и документируются. При этом, поскольку проекту могут угрожать не только простые риски, но и так называемые сложные, которые являются следствием ряда частных, описываются также и взаимосвязи рисков между собой.
Оценка влияния рисков • Для ранжирования рисков по значимости целесообразно ввести понятие ожидаемой величины риска (ОВР). ОВР вычисляется как произведение вероятности возникновения риска на оценку последствий возможной его реализации. Например, если потеря 300 долл. произойдет с вероятностью 100%, то ОВР равен 300 долл. , а при вероятности выхода из строя 10 единиц оборудования, равной 20%, ОВР составляет 2 единицы оборудования. • Оцененные риски подвергаются группировке по степени их значимости, и определяется тот набор рисков, который будет контролироваться в ходе данного проекта. Методика отбора рисков для контроля варьируется от проекта к проекту и зависит от конкретного случая. • Например, может быть проведена оценка ОВР и стоимости мероприятий по предотвращению рисков, а затем к рассмотрению приняты только самые значимые риски, на работу с которыми хватит средств, заложенных в бюджете на управление рисками.
Контрмеры • Когда риски выявлены, описаны и оценены, необходимо приступить к планированию мероприятий по их предотвращению и/или снижению их влияния. Каждое подобное мероприятие включает в себя распределение обязанностей между участниками проекта. Для каждого из процессов управления проектными рисками определяются исполнитель определенного вида работ, и ответственное лицо, принимающее эти работы. Определяются также периодичность формирования отчетов и виды отчетной документации. • Для каждого из рассматриваемых рисков строится карта реагирования, которая включает в себя описание границ осуществляемых мероприятий, перечень персонала, вовлеченного в работу, оценку затрат, влияние риска на ход проекта, решение других связанных вопросов, и самое главное, план конкретных работ по реагированию на произошедшее событие.
Контроль процесса подразумевает постоянное наблюдение за факторами возникновения рисков и уведомление руководства об их появлении, а также отслеживание соответствия последовательности действий как реакции на риск ранее запланированной. Изменения в ходе проекта могут повлечь за собой появление новых рисков и устранение старых, поэтому контроль предполагает также отслеживание возможных изменений, и выходные данные этого процесса поступают на вход процесса идентификации рисков.
ИС управления рисками • @Risk Professional for Project; • Dekker TRAKKER; • Enterprise project; • ER Project 1000; • Intelligent Planner; • Mesa/Vista Risk Manager; • Risk Track; • Open Plan
Возможности систем
ВНЕДРЕНИЕ И ТИРАЖИРОВАНИЕ ИС
Виды основных технологий • Технология работы с заказчиком ИС на этапе закупки и совершенствования ПП • Технология организации внедрения ИС на фирмепотребителе • Технология сопровождения ИС фирмойразработчиком
Технология работы с заказчиком ИС • Особенности ведения переговоров в сфере ИТ. • Планирование работы с заказчиком. Технология ведения переговоров с заказчиком ИС по закупке ИС. • Уменьшение риска отказа клиента от предлагаемого проекта ИС. • Технология ведения переговоров с заказчиком ИС по совершенствованию продукта и Культура согласования.
Переговоры • Условно процесс подготовки к переговорам подразделяется на два этапа: организационная подготовка и содержательная подготовка. Эти два этапа тесно взаимосвязаны, так как характер предстоящих переговоров обусловливает организационные моменты. Например, в зависимости от содержания переговоров определяется необходимость привлечения экспертов. Однако и организационные вопросы оказывают влияние на содержательную сторону: плохо подготовленные переговоры ведут к осложнениям в их ходе и даже срыву.
Организационная подготовка предполагает: • определение места и времени встречи; • формирование делегации и назначение ее главы.
Содержательная подготовка • включает в себя: • проведение анализа проблемы и диагностики ситуации; • проведение <внутренних переговоров>; • определение переговорной позиции и возможных вариантов решения проблемы; • формулирование предложений и их аргументация; • подготовка инструкций участникам переговоров, а также документов и материалов
Технология ведения переговоров • Этапы подачи позиции • Стратегия ведения переговоров • Тактические приемы "торга" • Тактические приемы "совместного с партнером анализа проблемы" • Тактические приемы двойственного характера
Этапы подачи позиции • Этапы подачи позиции, или ведения переговоров, подразумевают последовательность решения следующих задач: взаимное уточнение интересов, точек зрения, концепций и позиций участников; • их обсуждение (в том числе выдвижение аргументов в поддержку своих взглядов, предложений, их обоснование); • согласование интересов и выработка договоренностей.
Стратегия ведения переговоров • Виды стратегий: "Торг" , "Совместный с партнером анализ проблемы « • "Торг" представляет собой такую стратегию ведения переговоров, при которой каждый из участников ориентирован на максимальную реализацию собственных интересов и целей и практически не учитывает то, насколько интересы и цели партнера будут реализованы. Он стремится "выторговать" наиболее выгодный для себя итоговый документ и ориентируется на собственную победу. • "Совместный с партнером анализ проблемы", который иногда называется партнерским подходом, нацелен на решение проблемы при максимальном удовлетворении интересов обеих сторон. • В реальной практике ведения переговоров ни одна из стратегий в "чистом" виде не применяется, поэтому в каждом конкретном случае следует говорить о доминирующей стратегии. При выборе в качестве таковой "торга" участник переговоров может добиться для себя ряда преимуществ, однако он рискует тем, что переговоры будут сорваны, а также тем, что договоренности окажутся плохо выполнимыми.
Тактические приемы "торга" • Стратегия "торга" осуществляется посредством различных тактических • • приемов и их модификаций. ". "завышение первоначальных требований" предполагает, что вы, начиная переговоры, запрашиваете значительно больше того, что реально надеетесь получить. "выдвижение требований в последнюю минуту" заключается в том, что одна из сторон в конце переговоров, когда практически становится очевидным успешное их завершение, выдвигает новые требования. При этом участник исходит из того, что партнер, будучи крайне заинтересованным в подписании предварительно достигнутых договоренностей, пойдет на уступки. "выдвижение требований по возрастающей". Например, видя, что партнер соглашается с вносимыми вами предложениями, вы выдвигаете новые. двойного толкования" предполагает, что в ходе переговоров в итоговый документ вами "закладывается" формулировка, содержащая двойной смысл, что позволит вам в будущем трактовать соглашение в своих интересах, не нарушая при этом его формально,
приемы "совместного с партнером анализа проблемы" • "постепенного повышения сложности" обсуждаемых вопросов. Он подразумевает, что переговоры начинаются с легких вопросов, а затем их участники переходят к сложным. При этом достижение договоренностей по конфликтным вопросам оказывает положительное психологическое воздействие на участников, демонстрируя принципиальную возможность достижения взаимоприемлемых решений. • "разделение проблемы на отдельные составляющие" обычно используется в сложных переговорах, при наличии конфликтных отношений сторон. В этом случае на первых двух этапах ведения переговоров выявляются эти составляющие, а затем, при невозможности достижения договоренности по тем или иным компонентам, решается вопрос о вынесении их "за скобки", т. е. об отказе от рассмотрения их в ходе данных переговоров. При использовании данного приема реализуется лишь частичное соглашение
Тактические приемы двойственного характера • Некоторые приемы, будучи сходными по своему проявлению, тем не менее могут применяться либо при "торге", либо при "совместном с партнером анализе проблемы". • Используют приемы: -пакетирование; -уход; -пробный шар. • Одним из таких двойственных приемов является "пакетирование" при котором несколько предложений увязываются и предлагаются к рассмотрению в виде "пакета". "Пакет" в рамках торга предполагает увязывание привлекательных для другой стороны предложений с мало приемлемыми для нее (по сути - "продажу в нагрузку"). Сторона, предлагающая "пакет", исходит из того, что партнер, будучи крайне заинтересованным в нескольких предложениях из этого "пакета", примет и остальные.
Тактические приемы двойственного характера • "Уход" (завуалированный отказ от обсуждения или принятия предложения) применяется при "торге", если затрагиваются вопросы, которые на данный момент нежелательны для обсуждения по тактическим соображениям. В рамках "партнерского подхода" он может представлять собой, например, просьбу об объявлении перерыва с целью проведения неформальных консультаций. • "пробный шар". Суть его в том, что предложение формулируется в виде идеи, которая ни к чему не обязывает. Партнеру предлагается ответить на вопрос "а что, если? ". Нередко противоположная сторона начинает реагировать на эту формулировку, как на предложение, и обсуждать перспективы его реализации. Инициатор же при такой постановке вопроса, выслушав партнера, имеет возможность "забрать" свое предложение назад, не рискуя потерять репутацию.
Типичные ошибки при ведении переговоров • подготовке к переговорам не уделяется должного внимания. Участники полагают, что на самих переговорах легче будет решить все вопросы. На самом деле подготовка к переговорам, по данным ряда исследователей, должна занимать до 80% и даже более от общего времени (т. е. времени, отведенного на подготовку и ведение переговоров); • за столом переговоров возникают споры внутри делегации (ведутся "внутренние переговоры"), что недопустимо. Если какие-то вопросы остались несогласованными внутри делегации или возникли новые проблемы, следует предложить партнеру сделать перерыв; • не учитываются особенности делового общения и этикета партнера из другой страны, что ведет к взаимонепониманию на переговорах.
Типичные ошибки при ведении переговоров • в ходе переговоров участники не достаточно внимания уделяют тому, как конкретно могут быть реализованы их предложения. Прорабатывая предложения, обязательно решите вопросы возможной их реализации; • избегайте включать в делегацию тех, кто не обладает достаточным уровнем профессионализма. Это может отрицательно повлиять на ваш имидж; • нередко завышается количественный состав делегации, что ведет к снижению эффективности работы на переговорах. Старайтесь обойтись <меньшими силами>, но они должны быть высококвалифицированными;
Управление разработками ИС.pptx