Введение
Процесс проектирования организационных систем основан на совместном применении взаимодополняющих методов. Одной из важнейших задач управления на современном этапе является исследование и совершенствование методологии проектирования организационных систем в соответствии с изменяющимися условиями.
Научно обоснованное проектирование организационных систем – актуальная задача современного этапа адаптации хозяйствующих субъектов к рыночной экономике. В новых условиях необходимо широко использовать принципы и методы проектирования организации на основе системного подхода.
Без развития методов проектирования организационных систем будет затруднено дальнейшее совершенствование управления и повышение эффективности производства. В новых условиях в целом ряде случаев нельзя оперировать старыми организационными формами, которые не удовлетворяют требованиям рыночных отношений, создают опасность деформации самих задач управления. Создание структуры должно опираться не только на опыт, аналогию, привычные схемы и интуицию, но и на научные методы организационного проектирования.
1. Методология проектирования организационных систем
Процесс организационного проектирования состоит в последовательности приближения к модели рациональной структуры управления, в котором методы проектирования играют вспомогательную роль при рассмотрении, оценки и принятия к практической реализации наиболее эффективных вариантов организационных решений.
Проектирование организационных систем – сложный процесс. Специфика подобного проектирования заключается в том, что нет однозначного критерия оптимальности. Как всякая многокритериальная проблема, она для своего решения требует сочетания различных методов.
Методы проектирования организационных систем:
· Системный подход;
· Метод аналогий (метод функционального моделирования);
· Нормативный метод (или экспертно-аналитический метод);
· Метод структуризации целей;
· Метод организационного моделирования.
Системный подход основан на представлении о системе как о чём-то целостном, обладающем новыми свойствами по сравнению со свойствами составляющих её элементов. Новые свойства при этом понимаются очень широко. Они могут выражаться, в частности, в способности решать новые проблемы или достигать новых целей. Для этого требуется определить границы системы, выделив её из окружающего мира, и затем соответствующим образом изменить и преобразовать.
Основные принципы системного подхода:
· Целостность, позволяющая рассматривать одновременно систему как единое целое и в то же время как подсистему для вышестоящих уровней.
· Иерархичность строения, то есть наличие множества (по крайней мере, двух) элементов, расположенных на основе подчинения элементов низшего уровня элементам высшего уровня. Реализация этого принципа хорошо видна на примере любой конкретной организации. Любая организация представляет собой взаимодействие двух подсистем: управляющей и управляемой. Одна, как правило, подчиняется другой.
· Структуризация, позволяющая анализировать элементы системы и их взаимосвязи в рамках конкретной организационной структуры. Как правило, процесс функционирования системы обусловлен не столько свойствами её отдельных элементов, сколько свойствами самой структуры.
· Множественность, позволяющая использовать множество кибернетических, экономических и математических моделей для описания отдельных элементов и системы в целом.
Системный подход - это подход, при котором любая система рассматривается как совокупность взаимосвязанных элементов (компонентов), имеющая выход (цель), вход (ресурсы), связь с внешней средой, обратную связь. Это наиболее сложный подход.
Развернутое определение системного подхода включает также обязательность изучения и практического использования следующих восьми его аспектов:
1. системно-элементного или системно-комплексного, состоящего в выявлении элементов, составляющих данную систему. Во всех социальных системах можно обнаружить вещные компоненты (средства производства и предметы потребления), процессы (экономические, социальные, политические, духовные и т. д.) и идеи, научно-осознанные интересы людей и их общностей;
2. системно-структурного, который заключается в выяснении внутренних связей и зависимостей между элементами данной системы и позволяет получить представление о внутренней организации (строении) исследуемой системы;
3. системно-функционального. Предполагает выявление функций, для выполнения которых созданы и существуют соответствующие системы;
4. системно-целевого, означающего необходимость научного определения целей и подцелей системы, их взаимной увязки между собой;
5. системно-ресурсного. Заключается в тщательном выявлении ресурсов, требующихся для функционирования системы, для решения системой той или иной проблемы;
6. системно-интеграционного, состоящего в определении совокупности качественных свойств системы, обеспечивающих её целостность и особенность;
7. системно-коммуникационного, означающего необходимость выявления внешних связей данной системы с другими, то есть, её связей с окружающей средой;
8. системно-исторического, позволяющего выяснить условия во времени возникновения исследуемой системы, пройденные ею этапы, современное состояние, а также возможные перспективы развития.
Практически все современные науки построены по системному принципу. Важным аспектом системного подхода является выработка нового принципа его использования - создание нового, единого и более оптимального подхода (общей методологии) к познанию.
Метод аналогий (метод функционального моделирования) заключается в использовании организационных форм управления, которые оправдали себя в организациях со схожими характеристиками. Здесь происходит выработка типовых структур управления и определение условий их применения.
Применение метода аналогий основано на двух подходах.
· Первый из них заключается в том, что выявляются главные организационные характеристики и соответствующие им организационные формы, которые эффективны для определенного набора исходных условий.
· Второй подход представляет, по сути, типизацию наиболее общих принципиальных решений построения и функционирования организаций. Типизация решений является средством повышения общего уровня организации управления. Однако типовые решения не должны быть однозначными и их необходимо регулярно корректироваться и допускать отклонения по ряду параметров.
Нормативный метод (экспертно-аналитический метод) заключается в аналитическом изучении и исследовании организации, проводимыми квалифицированными специалистами с привлечением руководства организации.
Данный метод имеет многообразные формы реализации:
1. Диагностический анализ проблем и «узких мест» в управлении;
2. Проведение экспертных опросов;
3. Применение научных принципов формирования организационных систем;
4. Разработка графических и табличных описаний процессов управления и организационных структур.
Метод структуризации целей предусматривает выработку целей организации и оценку организационных систем с точки зрения соответствия их системе целей.
Использование этого метода предусматривает выполнение следующих этапов:
1. Разработка дерева целей исходя из конечных результатов;
2. Экспертный анализ предлагаемых вариантов организационных систем с точки зрения обеспечения целей;
3. Составления карт прав и ответственности за достижение целей.
Метод организационного (параметрического) моделирования представляет собой разработку формализованных математико-кибернетических, графо-аналитических, математико-статистических и натуральных моделей организационных структур. С помощью данного метода происходит синтез организационных систем на основе анализа и исследования сложившихся соотношений между характеристиками организации управления и систем управления.
Процесс проектирования основан на совместном применении вышеперечисленных методов. Выбор определенного метода зависит от характеристики организации, от возможностей проведения исследований, квалификации разработчиков.
Методология проектирования организационных систем должна быть организована в соответствии с общими для любой практической деятельности закономерностями, то есть должна иметь свои фазы, стадии и этапы, свою логическую и временную структуру, а так же свои характеристики. (Рис. 1.1. отражает специфику таких этапов)
Рис. 1.1. Логика постановки и решения задачи
В основании методологии проектирования лежит культура управления качеством и непрерывных улучшений. Ее использование позволило по-новому подойти к вопросам разработки стратегии, процессов и подсистем управления. Модель организационного проектирования состоит из четырех основных этапов. (Рис. 1.2.)
Рис. 1.2. Цикл организационного проектирования систем
Этапы взаимосвязаны и образуют замкнутый цикл, в котором оценка результатов внедрения является материалом для дальнейшего моделирования изменений и улучшений действующей модели.(Рис. 1.3.)
Рис. 1.3. Этапы цикла
Для модели основа - не бюрократический способ управления, свойственный большинству крупных организаций, а менеджмент качества и культура постоянных совершенствований.
Одним из подходов к управлению крупными организациями является менеджмент качества. В основе теории менеджмента качества (МК) - фундаментальный вопрос: как обеспечить производство и продажу качественной продукции экономически эффективным образом? Основой управленческой системы становится непрерывное совершенствование всех типов производственных и организационно-управленческих процессов. Главным в моделировании организационной деятельности становится процессный подход, позволяющий с единых методологических позиций проектировать, анализировать и осуществлять поиск резервов повышения качества и эффективности процессов различной природы. Под качеством стоит понимать уровень гармонизации производственных и организационных процессов, соответствия их выходов требованиям внутренних и внешних потребителей, общесистемным целям. Полное использование резервов повышения качества и эффективности возможно только в том случае, если система организационных механизмов стимулирует коллективные действия, обеспечивает мобилизацию интеллектуального потенциала работников, осуществляющих процессы. Для этого в крупных компаниях, использующих такой стиль управления, создается система организационных политик и стандартов, стимулирующих приверженность работников корпоративным целям, взаимодействие в команде и единую корпоративную культуру.
Классификация информационных систем по характеру использования информации
Классификация информационных систем по степени автоматизации
Основные понятия технологии проектирования
Лекция № 1
ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
Лекции по предмету информационных систем (ИС)
Информационная система (ИС) — это система, предназначенная для ведения информационной модели, чаще всего — какой-либо области человеческой деятельности. Эта система должна обеспечивать средства для протекания информационных процессов:
· хранение
Системы , которые осуществляют хранение и обработку информации называют информационно-вычислительными системами. В информационную систему данные поступают от источника информации. Эти данные отправляются на хранение либо претерпевают в системе некоторую обработку и затем передаются потребителю.
Между потребителем и собственно информационной системой может быть установлена обратная связь. В этом случае информационная система называется замкнутой . Канал обратной связи необходим, когда нужно учесть реакцию потребителя на полученную информацию.
Информационная система состоит:
o источника информации,
o аппаратной части ИС,
o программной части ИС,
o потребителя информации.
- Ручные информационные системы характеризуются отсутствием современных технических средств переработки информации и выполнением всех операций человеком. Например, о деятельности менеджера в фирме, где отсутствуют компьютеры, можно говорить, что он работает с ручной ИС.
- Автоматизированные информационные системы (АИС) — наиболее популярный класс ИС. Предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль отводится компьютеру.
- Автоматические информационные системы выполняют все операции по переработке информации без участия человека, различные роботы. Примером автоматических информационных систем являются некоторые поисковые машины Интернет, например Google, где сбор информации о сайтах осуществляется автоматически поисковым роботом и человеческий фактор не влияет на ранжирование результатов поиска.
- Информационно-поисковые системы — программная система для хранения, поиска и выдачи интересующей пользователя информации.
- Информационно-аналитические системы — класс информационных систем, предназначенных для аналитической обработки данных.
- Информационно-решающие системы — системы, осуществляющие переработку информации по определенному алгоритму.
- управляющие
- советующие
- Ситуационные центры (информационно-аналитические комплексы)
С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС:
1. Традиционные архитектурные решения основаны на использовании выделенных файл-серверов (File-server) или серверов баз данных (Client-server).
2. Корпоративные информационные системы , базируются на технологии Internet (Intranet-приложения).
3. "Хранилища данных" (DataWarehouse) - интегрированные информационные среды, включающие разнородные информационные ресурсы.
4. Архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода, которые используются для построения глобальных распределенных информационных приложений (Service Oriented architecture SOA).
Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы. На первом этапе основным подходом в проектировании ИС был метод "снизу-вверх", когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.
Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.
Следующий этап связан с осознанием того факта, что существует потребность в достаточно стандартных программных средствах автоматизации деятельности различных учреждений и предприятий. Из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы начали проектироваться "сверху-вниз", т.е. в предположении, что одна программа должна удовлетворять потребности многих пользователей.
Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.
Согласно статистическим данным , собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.
В то же время , заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.
Таким образом, возникла насущная необходимость формирования новой методологии построения информационных систем.
Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.
Цель создания методологии построения информационных систем заключается в регламентации процесса проектирования ИС и обеспечении управления этим процессом с тем, чтобы гарантировать выполнение требований, как к самой ИС, так и к характеристикам процесса разработки.
Основными задачами, решению которых должна способствовать методология проектирования ИС, являются следующие:
- обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;
- гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;
- поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;
- обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).
Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.
Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования. Модель жизненного цикла отражает различные состояния системы, начиная с момента возникновения необходимости в данной ИС и заканчивая моментом ее полного выхода из употребления.
В настоящее время известны и используются следующие модели жизненного цикла :
- Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
- Поэтапная модель с промежуточным контролем предусматривает разработку ИС итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
- Спиральная модель На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.
На практике наибольшее распространение получили две основные модели жизненного цикла:
- каскадная модель (характерна для периода 1970-1985 гг.);
- спиральная модель (характерна для периода после 1986.г.).
В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.
Можно выделить следующие положительные стороны применения каскадного подхода:
- на каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности;
- выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Каскадный подход хорошо зарекомендовал себя при построении относительно простых ИС, когда в самом начале разработки можно достаточно точно и полно сформулировать все требования к системе. Основным недостатком этого подхода является то, что реальный процесс создания системы никогда полностью не укладывается в такую жесткую схему, постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ИС оказывается соответствующим поэтапной модели с промежуточным контролем.
Однако и эта схема не позволяет оперативно учитывать возникающие изменения и уточнения требований к системе. Согласование результатов разработки с пользователями производится только в точках, планируемых после завершения каждого этапа работ, а общие требования к ИС зафиксированы в виде технического задания на все время ее создания. Таким образом, пользователи зачастую получают систему, не удовлетворяющую их реальным потребностям.
Спиральная модель ЖЦ была предложена для преодоления перечисленных проблем. На этапах анализа и проектирования реализуемость технических решений и степень удовлетворения потребностей заказчика проверяется путем создания прототипов. Каждый виток спирали соответствует созданию работоспособного фрагмента или версии системы. Это позволяет уточнить требования, цели и характеристики проекта, определить качество разработки, спланировать работы следующего витка спирали. Таким образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный вариант, который удовлетворяет действительным требованиям заказчика и доводится до реализации.
Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым, активизируя процесс уточнения и дополнения требований.
Методология проектирования ИС охватывает три основные области :
- проектирование объектов данных, которые будут реализованы в базе данных;
- проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
- учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.
Проектирование информационных систем всегда начинается с определения цели проекта.
Цель проекта можно определить как решение ряда взаимосвязанных задач, включающих в себя следующие пункты:
- реализация требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;
- реализация требуемой пропускной способности системы;
- реализация требуемого времени реакции системы на запрос;
- реализация безотказной работы системы;
- реализация необходимого уровня безопасности;
- реализация простоты эксплуатации и поддержки системы.
Согласно современной методологии проектирования процесс создания ИС делится на следующие этапы (стадии) :
1. Формирование требований к системе: Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. На єтой стадии осуществляется моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Для этого необходимо определить требования заказчиков к ИС и отобразить их на языке моделей в требования к разработке проекта ИС так, чтобы обеспечить соответствие целям и задачам организации. На выходе этапа получаем модель организации, описанную в терминах бизнес-процессов и бизнес-функций.
2. Проектирование: На этапе проектирования формируются модели данных. Проектировщики в качестве исходной информации получают результаты анализа требований к ИС. Построение логической и физической моделей данных является основной частью проектирования базы данных. Полученная в процессе анализа информационная модель сначала преобразуется в логическую, а затем в физическую модель данных. Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. При проектировании модулей определяют интерфейсы программ: разметку меню, вид окон, горячие клавиши и связанные с ними вызовы.
Конечными продуктами этапа проектирования являются:
· схема базы данных (на основании ER-модели, разработанной на этапе анализа);
· набор спецификаций модулей системы (они строятся на базе моделей функций).
· технический проект ИС (техническое задание), эскизный проект, рабочая документация.
3. Реализация: На этапе реализации осуществляется создание программного обеспечения системы, установка технических средств, разработка эксплуатационной документации.
4. Тестирование: обычно оказывается распределенным во времени. После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:
- обнаружение отказов модуля (жестких сбоев);
- соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).
После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.
Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.
Затем весь комплект модулей проходит системный тест - тест внутренней приемки продукта, показывающий уровень его качества. Сюда входят тесты функциональности и тесты надежности системы.
Последний тест информационной системы - приемо-сдаточные испытания. Такой тест предусматривает показ информационной системы заказчику и должен содержать группу тестов, моделирующих реальные бизнес-процессы, чтобы показать соответствие реализации требованиям заказчика.
Как известно, каждый проект – это уникальное мероприятие, не поддающееся стандартизации. Однако процессы управления проектами поддаются стандартизации и документы, которые формализуют эти процессы, получили название методологий управления проектами. Причем некоторые методологии управления проектами применимы для всех типов проектов в разных областях. Другие же, напротив, подходят только для управления конкретными типами проекта. Так, для сферы дорожного строительства наиболее подходящей будет одна проектная методология, в то время как для проекта по разработке программного обеспечения – другая. Рассмотрим ниже наиболее часто применяемые методологии управления проектами.
Традиционная (Каскадная) методология управления проектами
Традиционная методология управления проектами может быть использована во всех отраслях, но наиболее распространена в строительстве. Она также носит название каскадной или водопадной модели, вследствие того, что предлагаемая ею последовательность фаз напоминает поток. Методология выделяет семь последовательных этапов проектного управления:
- Определение требований
- Проектирование
- Реализация (строительство, производство…)
- Внедрение
- Тестирование и отладка
- Установка
- Эксплуатация и сопровождение
Переход к следующей фазе проекта возможен только в том случае, если предыдущий этап завершён и принят заказчиком. Применение данной методологии наиболее предпочтительно в проектах, результатом выполнения которых является материальный продукт (например, строительные проекты, установка оборудования и пр.) и для реализации которых требуется конкретная последовательность действий. Кроме того, разработанные планы возможно использовать повторно для аналогичных проектов в будущем.
Однако с другой стороны, каскадная модель управления проектом требует инвестиций в планирование. Обычно первые две фазы занимают от 20 до 40% от всего времени выполнения проекта по данной методологии. Вследствие структурированного подхода, внесение изменений в содержание работ происходит медленно, что делает методологию не гибкой и не подходящей в случаях, если клиент не уверен, какой результат он хочет получить.
Методология управления проектами PRINCE 2
PRINCE2 (Projects in Controlled Environments) так же является структурированной методологией к проектному управлению. Это одна из самых популярных методологий управления проектами, широко используемая в Великобритании в управлении как в бизнесе, так в органах власти. PRINCE2 – это процессно-ориентированная проектная методология, которая фокусируется на процессах верхнего уровня (управление, организация, контроль), а не на низших задачах (декомпозиция работ, разработка графиков). Методология PRINCE2 базируется на семи принципах, семи темах и семи процессах. Принципы являются центральным элементом методологии: если хотя бы один из них не выполняется, то нельзя говорить о том, что проект выполняется в рамках PRINCE2.
Принципы методологии PRINCE2:
- Постоянная оценка экономической необходимости — остается ли неизменной экономическая выгода от проекта на протяжении всего жизненного цикла проекта
- Обучение на опыте – команда проекта должна постоянно искать и изучать опыт предыдущих проектов
- Определение ролевой модели – команда проекта должна иметь ясную организационную структуру и вовлекать подходящих людей для решения нужных задач
- Управление по этапам – необходимо, чтобы проекты были спланированы, а также подвергались мониторингу и контролю на каждом этапе выполнения;
- Управление по отклонениям – следует четко обозначить допустимые границы отклонений в проекте, чтобы установить границы ответственности
- Фокус на продуктах – необходимо концентрироваться на определении и достижении качества продуктов (результатах проекта)
- Адаптация к проектной среде – следует адаптировать процессы и инструменты управления проектом к требованиям проектной среды, а также к масштабу работ, их сложности, важности, квалификационным требованиям и степени риска
Аспекты представляют собой направления проектного управления, на которые следует обращать внимание в течение длительности всего проекта.
Аспекты методологии управления проектами PRINCE2 :
- Обоснование проекта: какую ценность проект принесёт организации?
- Организация : каким образом необходимо распределить роли и ответственность между членами проектной команды для того, чтобы эффективно управлять проектом
- Качество : какие имеются требования и критерии к качеству и каким образом можно их обеспечить
- Планы : шаги, требуемые для разработки плана, и инструменты PRINCE2, необходимые к использованию
- Риски : каким образом менеджмент проекта будет разрешать проблему наличия неопределённостей в плане проекта и во внешней среде
- Изменение : как руководство проекта будет оценивать влияние непредвиденных задач и изменений и реагировать на них
- Прогресс : реализуемость проекта, выполнение планов и дальнейшее развитие проекта
Наконец, семь процессов разбивают жизненный цикл проекта на различные фазы, для каждой из которой имеются свои рекомендуемые к принятию действия, получаемые продукты и зоны ответственности.
PRINCE2 подразумевает следующие процессы управления проектом:
- запуск проекта
- руководство проектом
- инициация проекта
- контроль этапов
- управление созданием продукта
- управление границами этапов
- закрытие проекта
PRINCE2 позволяет стандартизировать процедуры управления проектами, улучшить координацию деятельности, а также помогает понять, каким образом следует планировать проект и осуществлять мониторинг его выполнения, что следует делать, если план проекта не выполняется. Однако методология PRINCE2 не является лучшим выбором для проектов небольшого масштаба или для проектов с большей степенью вероятности изменений объема работ и требований к ним.
Гибкая методология управления проектом (Agile Project Management)
Гибкое управление проектом представляет собой поступательную и итеративную проектную методологию. Ее главной особенностью является то, что в начале выполнения проекта точно неизвестно, каким должен быть конечный продукт и каким будет жизненный цикл проекта. Вместо этого, проектная деятельность разбивается на несколько итеративных фаз, называемых «спринтами». Каждый спринт состоит из множества задач и имеет свой конечный продукт и результат. Методология Agile позволяет менеджерам проектов постоянно получать обратную связь и улучшать продукт после каждой итерации.
В соответствии с данной методологией управления проектами, ответственность за результат делится между тремя ролями:
- Владелец продукта – определяет проектные цели, разрабатывает оптимальный график при заданных проектных параметрах, адаптирует процесс выполнения проекта к изменившимся требованиям и устанавливает приоритеты в характеристиках продукта
- Scrum мастер – устанавливает приоритеты в выполнении задач командой проекта и устраняет возникающие затруднения, препятствующие этому
- Члены команды – выполняют большинство поставленных задач, осуществляют ежедневный менеджмент, создают отчеты о ходе выполнения проекта, контролируют качество продукта
Методология Agile является гибкой и позволяет легко изменить параметры проекта, что является значимым для таких сервисно-ориентированных проектов, как разработка программного обеспечения или графический дизайн. Но это методология не подходит для проектов со строго заданными параметрами и требованиями.
Методология быстрой разработки приложений (Rapid Application Development — RAD)
Быстрая разработка приложений (RAD) – это проектная методология, чаще всего используемая в проектах по разработке ПО, основной целью которых является быстрое и качественное создание приложения. Данная методология управления проектами выделяет 4 стадии проекта:
- Планирование
- Пользовательское проектирование
- Быстрое конструирование
- Переключение
Методология быстрой разработки приложений, с одной стороны, помогает улучшить показатели результативности проекта и повысить качество риск-менеджмента. Но с другой стороны, данная метрология не подходит для масштабных IT проектов, может привести к низкому качеству кода и требует постоянного вовлечение клиента в процесс исполнения всего проекта
- Не существует универсальной «наилучшей» методологии управления проектом – выбор определяется типом проекта и спецификой окружающей среды
- Если вы работаете над проектом с возможными небольшими изменениями содержания работ, например, в области строительства, выбирайте каскадную модель
- Для разработки программного обеспечения, графического дизайна и других сервисно-ориентированных проектов выбирайте Agile методологию
- Используйте методологию быстрой разработки приложений для небольших IT проектов с сжатыми сроками
- Если вам необходимо минимизировать риски и требуются структурированный подход в исполнении крупного или среднего масштаба проекта, выбирайте PRINCE2
- Не бойтесь использовать другие, менее популярные методологии, если они в большей степени подходят к вашему проекту
Функциональный метод проектирования Мэтчетта комплексный эвристический метод технического творчества, в котором одновременно используются следующие "режимы мышления".
Мышление стратегическими схемами
(выработка стратегии и соблюдение
стратегии).
Мышление в параллельных плоскостях
(проектировщик, с одной стороны, думает,
а с другой наблюдает процесс мышления).
Мышление с нескольких точек зрения
(часто оно осуществляется с помощью
контрольных вопросов, данных ниже).
Мышление "образами"
(образы могут быть как идеальными, так и реальными: в виде
схем, загадочных, заманчивых рисунков, т. к. в методе особое внимание обращается на
положительное влияние эмоции в процессе проектирования.
Мышление с использованием основных элементов.
Основные элементы это
слова, которые используются в процессе решения каждой задачи. Мэтчетт назвал их
течтэмами, прочитав свою фамилию справа налево.
Течтэмы объединены в семь групп:
- Варианты решений определить потребность, определить необходимый элемент, представить себе решение, принять временное решение, принять окончательное решение, отменить решение;
- Варианты суждений предположить, взвесить, взвесить и сравнить, экстраполировать, оставить без изменения, предсказать;
- Варианты стратегий продолжать в том же направлении, продолжать и расширить, изменить направление, сопоставить с прошлым, сопоставить с будущим, внимательно рассмотреть, разрешить конфликт, продолжать более интенсивно, прекратить;
- Варианты тактик оценить риск, проверить последствия, развить, сравнить с другими решениями, разделить действие, приспособить другое решение, сосредоточиться на малом участке, разложить на компоненты, проверить возможную причину, обдумать возможность нового решения, заменить решение на противоположное, проверить другие варианты;
- Варианты отношений хранить решение в памяти, выявить зависимость, отсрочить принятие решения, сообщить о решении, соотнести с ранее принятым решением, проверить на избыточность, проверить на несоответствие;
- Варианты понятий использовать новое понятие, изменить плоскость абстракции, использовать схему стратегии, изменить точку зрения, сравнить с существующей системой, сравнить с получающейся системой, применить первичное кольцо (см. группу 5 и перечень вопросов, данный ниже), применить вторичное кольцо (см. группу 6 и перечень вопросов, данный ниже);
- Варианты препятствий обойти препятствие, разрушить препятствие, устранить препятствие, начать новое действие с нуля, начать новое действие с принятого решения, действовать в одном, двух, трех или многих измерениях.
"Режимы мышления" предназначены для осознания, контроля и приспособления образа мышления к задачам проектирования. Методом Мэтчетта используется перечень контрольных вопросов:
- Какие потребности являются: жизненно важными, очень важными, важными, желательными?
- Каковы потребности: функциональной системы, потребителя, фирмы, внешнего мира?
- Каковы потребности на каждом из перечисленных ниже 10 этапов существования изделия: проектирование и деталировка, отработка, изготовление деталей, сборка, испытание и отладка, окончательная отделка и упаковка, сбыт, монтаж, эксплуатация и использование, тех. обслуживание и уход?
- Какие сведения можно получить, если задать 6 основных вопросов анализа трудовых операций: что нужно сделать (потребности), почему это нужно сделать (причина), когда это нужно сделать (время), где это нужно сделать (место), кем или с помощью чего это должно быть сделано (средства), как это сделать (метод)?
- Каким образом каждую часть проекта можно: исключить, объединить с другими частями, унифицировать, перенести, модифицировать, упростить?
- Какие эффекты, потребности, ограничения вызовет каждая деталь комплекса в отношении любой др. детали этого комплекса?
Очень большое внимание Мэтчетт уделил вопросам самоконтроля и самонастройки на всех этапах процесса проектирования, а также использованию логосинтеза (синтез с помощью разговора). Метод Мэтчетта можно представить как сбалансированную смесь опыта, искусства, психоанализа, "групповой динамики", самовнушения, внушения и некоторой доли мистики.
Проектирование — процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или её части (ISO 24765). Результатом проектирования является проект — целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы.
Проектирование, наряду с анализом требований, является частью большой стадии жизненного цикла системы, называемой определением системы (англ. system definition). Результаты этой стадии являются входной информацией для стадии реализации (воплощения) системы (англ. system realization).
Проектирование системы направлено на представление системы, соответствующее предусмотренной цели, принципам и замыслам; оно включает оценку и принятие решений по выбору таких компонентов системы, которые отвечают её архитектуре и укладываются в предписанные ограничения.
В настоящее время существует сильная тенденция рассматривать архитектурное и детальное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с «обычными» проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы. Детальное проектирование, в свою очередь, определяется как процесс детализации и расширения предварительного проекта (архитектуры) до такой степени, при которой проект полностью готов к реализации.
Внутри процесса проектирования, наряду с расчетными этапами и экспериментальными исследованиями, часто выделяют процесс конструирования.
Конструирование — деятельность по созданию материального образа разрабатываемого объекта, ему свойственна работа с натурными моделями и их графическими изображениями (чертежи, эскизы, компьютерные модели). Эти модели и изображения, а также некоторые виды изделий называют конструкциями. Например, конструирование форм одежды, конструирование интерьеров, разработка конструкции машины, конструктивные и объёмно-планировочные решения объекта капитального строительства, металлоконструкция, строительные конструкции.
Виды проектирования
По отраслям деятельности
По видам разрабатываемых объектов выделяют следующие виды проектной деятельности:
Ø Проектирование технических систем, в том числе
§ техническое проектирование (технические устройства и оборудование);
§ электротехническое проектирование (электротехника и электроснабжение);
§ проектирование инженерных систем (вентиляции, газопроводов, электросетей и др.инфраструктуры);
Ø Строительство, в том числе
§ архитектурно-строительное проектирование;
§ градостроительное проектирование;
§ технологическое проектирование;
Ø Дизайн, в том числе
§ дизайн интерьера;
§ промышленный дизайн;
§ ландшафтный дизайн;
Ø Проектирование программного обеспечения;
Ø Социальное проектирование, социология (определение вариантов развития социальных процессов и явлений с целью коренного изменения конкретных социальных институтов. Применяется при проектировании новых городов и новых производств), в том числе
§ прогнозное социальное проектирование (социальная технология, ориентированная на выработку образцов решений перспективных социальных проблем с учётом доступных ресурсов и намеченных целей социально-экономического развития. Его цель — предплановое научное обоснование управленческих решений.
Ø другие виды проектирования.
По подходу к проектированию
Функциональное проектирование
Любой объект служит лишь материальным носителем функции, то есть функция — первична, объект — вторичен и создается по причине невозможности иными, нематериальными средствами удовлетворить потребности людей. Так, автомобиль нужен для перевозки грузов и людей (функция — перемещать в пространстве, создан вследствие нереальности перемещения предметов только усилием мысли), назначение ручки — писать, а книги — хранить информацию и т. д.
Наряду со словом «функция» часто используется слово «назначение», особенно при рассмотрении не технических объектов.
Функциональное проектирование нацелено, прежде всего, на создание эффективно работающего объекта. Выполнение требуемой функции — главная цель и основа разработки объекта. Во внимание принимаются, прежде всего, функциональные показатели качества и показатели надёжности.
Оптимальное проектирование
Процесс проектирования всегда подчинён необходимости учёта интересов двух групп людей: производителей и потребителей продукции (товаров, работ, услуг). Каждая из групп стремится к удовлетворению своих требований к продукции, часть из которых может быть взаимоисключающей. Также, процесс решения практической задачи всегда многовариантен, и перед разработчиком встаёт проблема аргументированного выбора окончательного варианта. Например, автомобиль должен не только обладать высокой скоростью и мощностью двигателя, но и низкой стоимостью, комфортабельностью, экологичностью, быть выгодным для производителя и т. д.
Проектирование, целью которого является не только поиск функционально эффективных решений, но и удовлетворение разных, порой противоречивых потребностей людей, обоснованный выбор окончательного варианта, стали называть оптимальным проектированием (критериальным проектированием, вариантным проектированием). Активно оно начало применяться со второй половины 20 века благодаря достижениям теории принятия решений и теории исследования операций и широкому распространению вычислительной техники, позволившим разработать соответствующие методы, в обозримые сроки просчитывать многочисленные варианты и решать сложные математические задачи.
Большое значение в оптимальном проектировании отводится подготовке на этапе технического задания полного перечня требований к разрабатываемому объекту, выделению среди них показателей качества и преобразованию наиболее важных из них в критерии оптимизации. Показателен в этой связи девиз одной японской фирмы — «Мы не создаем технику, мы создаем человека».
К типовым требованиям к научно-технической продукции относят требования функциональные (показатели назначения), надёжности, технологичности, стандартизации и унификации, ограничения вредных воздействий (эргономичность и экологичность), эстетичность, экономичность, патентно-правовые. Требования к другим видам продукции во многом совпадают с перечисленными.
Системное проектирование
К концу XX века не только существенно возросла сложность проектируемых объектов, но и их воздействие на общество и окружающую среду, тяжесть последствий аварий из-за ошибок разработки и эксплуатации, высокие требования к качеству и цене, сокращению сроков выпуска новой продукции. Необходимость учёта этих обстоятельств заставляла вносить изменения в традиционный характер и методологию проектной деятельности.
При создании объектов их уже необходимо было рассматривать в виде систем, то есть комплекса взаимосвязанных внутренних элементов с определенной структурой, широким набором свойств и разнообразными внутренними и внешними связями. Сформировалась новая проектная идеология, получившая название системного проектирования.
Системное проектирование комплексно решает поставленные задачи, принимает во внимание взаимодействие и взаимосвязь отдельных объектов-систем и их частей как между собой, так и с внешней средой, учитывает социально-экономические и экологические последствия их функционирования. Системное проектирование основывается на тщательном совместном рассмотрении объекта проектирования и процесса проектирования, которые в свою очередь включают ещё ряд важных частей.
Основные части проектирования
Принципы системного проектирования
Системное проектирование должно базироваться на системном подходе. На сегодняшний день нельзя утверждать, что известен его полный состав и содержание применительно к проектной деятельности, однако можно сформулировать наиболее важные из них:
Нисходящее и восходящее проектирование
Ведение разработки объекта последовательно от общих черт к детальным называется нисходящим проектированием. Его результатом будут требования к отдельным частям и узлам. Возможен ход разработки от частного к общему, что образует процесс восходящего проектирования. Такое проектирование встречается, если одна или несколько частей уже являются готовыми (покупными или уже разработанными) изделиями.
Нисходящее и восходящее проектирование обладают своими достоинствами и недостатками. Так, при нисходящем проектировании возможно появление требований, впоследствии оказывающихся нереализуемыми по технологическим, экологическим или иным соображениям. При восходящем проектировании возможно получение объекта, не соответствующего заданным требованиям. В реальной жизни, вследствие итерационного характера проектирования, оба его вида взаимосвязаны.
Структура проектирования
Проектирование, как осознанная целенаправленная деятельность, обладает определённой структурой, то есть последовательностью и составом стадий и этапов разработки проекта, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.
В настоящее время существуют два представления структуры проектирования, подобные по форме, но различные по целям и подходам к деятельности. Это — структура в виде стадий разработки проектной документации (стадий проектирования) и структура процесса проектирования.
§ Стадии проектирования
§ Стадии разработки проектной документации
Стадии проектирования регламентированы стандартами ГОСТ 2.103-68 и ГОСТ Р 15.201-2000. Последовательность выполнения всех стадий образует официальную структуру процесса разработки проектной документации, которая, как правило, используется при официальных взаимоотношениях между заказчиком и исполнителем или между соисполнителями работ. Сама документация необходима для отчета перед заказчиком о проделанной работе, возможности проверки или повторения разработок другими исполнителями, подготовки производства и обслуживания изделия в период эксплуатации.
Стадии создания других систем регламентируются своими стандартами, например, для автоматизированных систем — ГОСТ 34.601-90.
Структура устанавливает стадии разработки конструкторской документации на изделия всех отраслей промышленности и этапы выполнения работ внутри каждой стадии, то есть состав документации и виды работ, что помогает ответить на вопрос «Что нужно делать?» в процессе проектирования. Основные стадии структуры включают:
Эскизный проект (ЭП) — совокупность документов, содержащих принципиальные решения и дающих общее представление об устройстве и принципе работы разрабатываемого объекта, а также данные, определяющие его назначение, основные параметры и габаритные размеры. В случае большой сложности объекта этому этапу может предшествовать аван-проект (предпроектное исследование), обычно содержащий теоретические исследования, предназначенные для обоснования принципиальной возможности и целесообразности создания данного объекта.
При необходимости на стадии ЭП проводят изготовление и испытание макетов разрабатываемого объекта.
Технический проект (ТП) — совокупность документов, которые должны содержать окончательные технические решения, дающие полное представление об устройстве проектируемого объекта, исходные данные для разработки рабочей документации.
На стадии рабочего проекта (РП) сначала разрабатывают подробную документацию для изготовления опытного образца и последующего его испытания. Испытания проводят в ряд этапов (от заводских до приемо-сдаточных), по результатам которых корректируют проектные документы. Далее разрабатывают рабочую документацию для изготовления установочной серии, её испытания, оснащения производственного процесса основных составных частей изделия. По результатам этого этапа снова корректируют проектные документы и разрабатывают рабочую документацию для изготовления и испытания головной (контрольной) серии. На основе документов окончательно отработанных и проверенных в производстве изделий, изготовленных по зафиксированному и полностью оснащенному технологическому процессу, разрабатывают завершающую рабочую документацию установившегося производства.
Завершает цикл работ этап, подводящий итог проектной деятельности, — сертификация . Её назначение — определение уровня качества созданного изделия и подтверждение его соответствия требованиям тех стран, где предполагается его последующая реализация. Необходимость выделения этого этапа в виде самостоятельного вызвана тем, что в настоящее время экспорт продукции или её реализация внутри страны во многих случаях недопустимы без наличия у неё сертификата качества. Сертификация может быть обязательной или добровольной. Обязательной сертификации подлежат товары, на которые законами или стандартами установлены требования, обеспечивающие безопасность жизни и здоровья потребителей, охрану окружающей среды, предотвращение причинения вреда имуществу потребителя. Добровольная сертификация проводится по инициативе предприятий. Обычно это делается с целью официального подтверждения характеристик продукции, изготавливаемой предприятием, и, как следствие, повышения доверия к ней у потребителей.
В процессе разработки проектной документации в зависимости от сложности решаемой задачи допускается объединять между собой ряд этапов. Этапы постановки ТЗ и технического проектирования могут входить в цикл научно-исследовательских работ (НИР), а этапы технического предложения и эскизного проектирования — образовывать цикл опытно-конструкторских работ (ОКР).
Проектирование — это ещё и целенаправленная деятельность, которая обладает последовательностью процедур, ведущих к достижению эффективных решений. Соответственно, должна быть структура процесса решения задачи проектирования, которая помогает ответить на вопрос «Как это делать?». В настоящее время предложен ряд структур и алгоритмов проектирования, совпадающих в основных чертах и различающихся только в содержании или названии отдельных этапов.
Решение любой задачи начинается с её осмысления и уточнения исходных данных. Те (технические) требования (ТТ), которые выдаются заказчиком, формулируются на языке потребителя-неспециалиста и не всегда бывают технически чёткими и исчерпывающими. Перевести требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, то есть сформулировать техническое задание (ТЗ), — первый и обязательный этап работы. Исполнитель выполняет его в тесном контакте с заказчиком.
В машиностроении этот этап иногда называют внешним проектированием. Этим подчеркивают, что разработка объекта уже начинается с постановки задачи (ТТ) и формирования ТЗ и активно ведётся совместно с заказчиком. Важным результатом этапа является согласование целей разработки и назначения проектируемого объекта (его функций), системы показателей качества.
Следующие этапы образуют внутреннее проектирование. Они нацелены на поиск решения задачи и выполняются разработчиком. Сюда входят этапы синтеза принципа действия, структуры и параметров проектируемого объекта:
На этапе синтеза принципа действия отыскивают принципиальные положения, физические, социальные и т. п. эффекты, которые составят основу функционирования будущего изделия. Это могут быть основополагающие нормы, фундаментальные законы и правила, их частные случаи или следствия. Работа ведется с принципиальными моделями и их графическим представлением — блок-схемами. Этому этапу соответствует заключительная стадия ТЗ и стадия технического предложения структуры проектирования по ГОСТ 2.103;
На этапе структурного синтеза на основе выбранного принципа действия создаются варианты начального графического представления объекта — структуры, схемы, алгоритмы, упрощённые эскизы. В соответствии с ГОСТ 2.103 этот этап включает стадию эскизного проектирования;
На этапе параметрического синтеза отыскиваются значения параметров объекта, находится численное, в том числе оптимальное, решение проектной задачи, создаётся подробная документация или описание объекта, чертежи изделия и его частей. Этот этап соответствует стадиям технического и рабочего проектирования.
Вследствие неполноты начальных знаний о задаче процесс проектирования — итеративен, с каждым циклом итерации цели проектирования всё более уточняются, появляется необходимость в дополнительных функциях и, как следствие, — потребность в разработке дополнительных частей и узлов. Решение частных проектных задач, дополняющих основное решение, также проводится в соответствии с представленной последовательностью.
На каждом этапе внутреннего проектирования выполняются следующие процедуры:
§ выбор модели (то есть основополагающего принципа, вида блок-схемы и расчетной схемы),
§ выбор метода решения, в том числе метода оптимизации,
§ решение,
§ анализ полученных результатов и принятие решения.
Замечено, что эффективность проектируемого объекта определяется: в первую очередь — выбранным принципом действия, во вторую — предложенной структурой и в третью — соотношением параметров.
Методы проектирования
Эвристические методы
§ Метод итераций (последовательного приближения)
§ Метод декомпозиции
§ Метод контрольных вопросов
§ Метод мозговой атаки (штурма)
§ Теория решения изобретательских задач (ТРИЗ)
§ Метод морфологического анализа
§ Функционально-стоимостной анализ
§ Методы конструирования
Экспериментальные методы
§ Цели и виды экспериментальных методов
§ Планирование эксперимента
§ Машинный эксперимент
§ Мысленный эксперимент
Формализованные методы
§ Методы поиска вариантов решений
§ Методы автоматизации процедур проектирования
§ Методы оптимального проектирования
Проектирование — это один из видов работ, результатом которых является продукция-проект. Поэтому участников этих работ можно разделить на потребителей (заказчиков проектных работ) и поставщиков (исполнителей этих работ). Исполнителя-специалиста по разработке проекта обобщенно называют проектировщиком или разработчиком. Если продукция создается для собственного потребления, то возможно соединение в одном лице заказчика и исполнителя.