Вопросы к экзамену «Шпора на экзамен по дисциплине Технология разработки программ и программного обеспечения НГТУ»

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

Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

- наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);

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

- необходимость интеграции существующих и вновь разрабатываемых приложений;

- функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

Введение в процесс разработки программного обеспечения

Разработка программного обеспечения является очень молодой и быстро развивающейся отраслью инженерной науки. Она подвержена постоянным и быстрым изменениям. Так, всего лишь в начале 90-х годов Британское сообщество вычислительной техники (British Computer Society) начало присваивать разработчикам программ звание инженера (Chartered Engineer), а в Соединенных Штатах только в 1998 году стало возможным хоть где-то (а точнее, в штате Техас) зарегистрироваться в качестве профессионального инженера программного обеспечения. Но по-прежнему, даже в начале двадцать первого века, общепризнанным остается тот факт, что разработке программного обеспечения не достает достаточно развитой научной базы. По некоторым оценкам, 75 % организаций, занимающихся разработкой программ, делают это на примитивном уровне. С другой стороны, в этой области сформировалось немало интересных идей, и знакомство с ними

Основные понятия и определения

Программное обеспечение (Software) - полный набор или часть программ, процедур, правил и связанной с ними документации системы обработки информации. (ИСО/МЭК 2382-1 1993) Примечание. ПО - интеллектуальный продукт, не зависящий от среды, на которой он записан.

Программные средства (Software product) -набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных. Примечание. Объем понятия, выражаемого термином "программные средства" включает в себя как частный случай объем понятия 'программное обеспечение".определяемого по Г'ОСТ 19781. [см. ГОСТ 28806-90. приложение 1 ]

Программный продукт (Software product) - набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных, предназначенных для передачи пользователю [ИСО/МЭК 12207]. Примечание. Продукты включают промежуточные продукты и продукты, предназначенные для пользователей типа разработчиков и персонала сопровождения

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

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

Технология разработки программного обеспечения должна охватывать разнообразные типы программ, включая перечисленные ниже.

- Автономное: устанавливаемое на одиночный компьютер; не связанное с другим программным и аппаратным обеспечением; пример - текстовый редактор.

- Встроенное: часть уникального приложения с привлечением аппаратного обеспечения; пример - автомобильный контроллер.

- Реального времени: должны выполнять функции в течение малого интервала времени, обычно нескольких микросекунд; пример - программное обеспечение радиолокатора.

- Сетевое: состоит из частей, взаимодействующих через сеть; пример - основанная на вебтехнологии видеоигра.

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

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости его создания и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 [5] (IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

Структура ЖЦ ПО по стандарту:

- основные процессы ЖЦ ПО : приобретение (заказ), поставка, разработка, эксплуатация, сопровождение.

- вспомогательные процессы, обеспечивающие выполнение основных процессов: документирование, управление конфигурацией, обеспечение качества, верификация, валидация (аттестация), оценка (совместный просмотр), аудит, решение проблем.

- организационные процессы: управление, создание и сопровождение инфраструктуры, усовершенствование, обучение.

Разработка включает в себя все работы по созданию ПО и его компонент в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала и т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и реализацию (программирование).

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

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

Управление конфигурацией является одним из вспомогательных процессов, поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих из многих компонентов, каждый из которых может иметь разновидности или версии, возникает проблема учета их связей и функций, создания унифицированной структуры и обеспечения развития всей системы. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и рекомендации конфигурационного учета, планирования и управления конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5].

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Каскадная модель процесса

Анализ требований - сбор требований к продукту. Результатом анализа, как правило, является некоторый текст/документ(ТЗ).

Проектирование - описывает внутреннюю структуру продукта. Обычно такое описание дается в форме диаграмм и текстов.

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

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

Положительные стороны применения каскадного подхода заключаются в следующем:

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

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

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

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Спиральная модель процесса

В случае спирального процесса (автор Барри Боэм,1988) последовательность анализ требований - проектирование - реализация - тестирование выполняется более одного раза.

Для этого может быть несколько причин:

- необходимость предупреждения рисков;

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

Версии продукта называют прототипами. Каждый виток спирали соответствует созданию фрагмента или версии ПО.

Т.о. углубляются и последовательно конкретизируются детали проекта. В результате выбирается обоснованный вариант, который доводится до реализации.

Дополнительное преимущество: на каждом витке спирали можно собрать метрические характеристики проекта (трудоемкость затрат, затраты на проект, длительность, документированность).

Т.о. уточняется план-график дальнейшей работы.

Минусы:

1. Требуется более искусное управление

2. Необходимость поддержки целостности документации, которая должна быть полностью сформирована к концу каждой версии.

3. Трудность в определении момента перехода на следующий этап.

4. Переход осуществляется в соответствии с планом даже если не все работы выполнены.

5. Слишком большое количество витков потребует увеличения затрат, больших затрат.

Типичный проект:

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

Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО (под моделью ЖЦ понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач, выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики условий, в которых последняя создается и функционирует). Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий разработки. Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не конкретизирует в деталях, как реализовать или выполнить действия и задачи, включенные в эти процессы.

К настоящему времени наибольшее распространение получили следующие модели ЖЦ:

- каскадная (водопадная) модель (70-85 г.г.);

- спиральная модель (86-90 г.г.).

- инкрементальная модель

Инкрементальная модель

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

Например, Кукумано и Сэлби [21] подготовили доклад по процессу, используемому в некоторых отделениях корпорации Microsoft, где обновления программного кода и документации предоставляются ежедневно к конкретному времени для интеграции и ночного тестирования. Другие организации используют для этого недельные циклы. Для поддержания соответствующего уровня инкрементальной разработки необходимo иметь четко установленную архитектуру проекта и исключительно синхронизированную систему документации (рис. 1.10). Для организации инкрементальной разработки обычно выбирается характерный временной интервал, например неделя. Затем в течение этого интервала происходит обновление исходного проекта (документации, набора тестов, программного кода и т.д.). Теоретически шаги разработки (increments) могут выполняться и параллельно, но такой процесс очень сложно скоординировать. Инкрементальная разработка проходит лучше всего, если следующая стадия п+1 начинается по возможности после того, как обновление всех модулей на стадии п закончено, и хуже всего, если время, требуемое на обновление модулей, значительно превышает выбранный интервал. Для того чтобы убедиться в этом, представьте, что необходимо изменить модуль 789, который зависит от семи других модулей: 890, 23, 489, 991, 7653, 2134 и 2314. Если изменение занимает девять недель, то модуль 789 должен быть построен исходя из предполагаемого состояния всех семи модулей через девять недель. Эту работу очень трудно скоординировать, так как каждая из семи частей может быть изменена до девяти раз (еженедельно), причем каждое новое изменение может основываться на исследовании эффективности предыдущих изменений.

1 План управления программным проектом

2 Проектная документация программного обеспечения

3 Спецификация требований к программному обеспечению

- экстремальное программирование XP (Кент Бек, 1999). Оно ориентировано на очень малые приращения функциональности.

- модель быстрой разработки приложений RAD (Rapid Application Development). RAD-модель обеспечивает эстремально короткий цикл разработки. Быстрая разработка достигается за счет использования компонентно ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD- процесс позволяет группе создать полностью функциональную систему за 60-90 дней.

Выделяют следующие этапы:

- бизнес-моделирование. Моделируются информационные потоки между бзнесм-функциями.

- моделирование данных. Информационный поток отображается в набор объектов данных.

- моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций.

- генерация приложения. Используются языки программирования 4-го поколения, готовые компоненты, для конструирования утилиты автоматизации.

- тестирование и объединение. Применение повторно используемых компонентов уменьшает время тестирования.

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

Недостатки применения RAD:

1. Для больших проектов требуются значительные людские ресурсы для создания групп.

2. Модель применима только для тех систем, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. Не применима в условиях высоких технических рисков, т.е. при использовании новой технологии.

В современной программной инженерии выделяют два семейства процессов разработки:

- прогнозирующие (predictive) или тяжеловесные (heavyweight) процессы - прогнозируется весь объем работ, большой объем документации, строгий порядок разработки, фиксированные требования и многочисленная группа разработчиков разной квалификации.

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

Экстремальное программирование - это облегченный процесс (Кент Бек, 1999). Он ориентирован на группы малого и среднего размера, работающие в условиях неопределенных и быстро изменяющихся требований. В группу входит до 10 сотрудников, работающих в одном помещении.

На всем протяжении итерационного цикла требования постоянно меняются, причем цикл состоит из очень коротких итераций.

Базовые действия на каждой итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

Динамизм обеспечивается следующими характеристиками:

- непрерывная связь с заказчиком;

- простота (всегда выбирается минимальное решение)

- быстрая обратная связь (модульное и функциональное тестирование)

- смелость в проведении профилактики возможных проблем.

Базис XP образуют 12 методов:

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

2. Частая смена версий новые версии каждые 2 недели.

3. Метафора -вся разработка проводится на основе простой общедоступной истории о том как работает система. Истории обеспечивают заказчики.

4. Простое проектирование

5. Тестирование - непрерывное написание тестов для модулей. Входным критерием для написания кода является отказавший тестовый вариант. Заказчики участвуют в тестировании.

6. Реорганизация - система реструктуризируется, но ее поведение не меняется. Цель упростить систему, улучшить взаимодействие или добавить в нее гибкость.

7. Парное программирование -весь код пишется двумя программистами, работающими на одном компьютере.. Оно приводит к повышению качества и уменьшению времени цикла на 40-50%, при увеличении затрат на ресурсы на 15%

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

9. Непрерывная интеграция -интегрирование системы несколько раз в день по мере завершения каждой задачи.

10. 40-часовая неделя -нельзя работать сверхурочно.

11. Локальный заказчик - в группе все время должен находиться представитель заказчика, готовый отвечать на все вопросы.

12. Стандарты кодирования - правила, обеспечивающие одинаковое представление программного кода.

К таким стандартам относятся следующие:

- стандарт проектирования;

- стандарт оформления проектной документации;

- стандарт пользовательского интерфейса.

Над данными стандартами работает ISO/IEС JTC1/SC7 - международный технический комитет стандартов под контролем ИСО (ISO - Международная организация по стандартизации) и МЭК (IEС - Международная электротехническая комиссия).

Стандарт проектирования устанавливает (ISO/IEC 2382-20: 1990, Information technology ~ Vocabulary - Part 20 : Systems development. (Разработка систем).):

- набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

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

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

- механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.), правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации устанавливает (ИСО 6592:1985, Обработка информации. Руководящие указания по документированию автоматизированных прикладных систем.):

- комплектность, состав и структуру документации на каждой стадии проектирования;

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

- правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

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

- требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя устанавливает (ИСО 6385:1981, Эргономические принципы проектирования рабочих систем):

- правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

- правила использования клавиатуры и мыши;

- правила оформления текстов помощи;

- перечень стандартных сообщений;

- правила обработки реакции пользователя.

Измерения помогают оценить как продукт, так и сам процесс его разработки. В результате измерений определяется мера - количественная характеристика какого-либо свойства объекта. Некоторые измерения позволяют сразу определить свойства объекта. А остальные можно получить лишь за счет вычисления от значений опорных характеристик. Результаты подобных вычислений называют метриками. Зачастую понятие мера и метрика рассматривают как равноценные определения.

Измерения при разработке ПО необходимы для того, чтобы:

- определить или показать качество продукции;

- оценить производительность труда персонала, занятого разработкой;

- оценить выгоды (прибыль или доход), которые могут быть получены в результате разработки новых программных средств;

- сформировать основу (базовую линию) для последующих оценок;

- получить данные для обоснования запросов на дополнительные средства, обучение и т.п.

Измерения бывают прямые и косвенные. Результаты прямых измерений процесса разработки и сопровождения программного изделия: трудозатраты и стоимость, число строк кода (LOC - lines-of-code), размер требуемой памяти, скорость выполнения программы, число ошибок (дефектов), обнаруженных за определенный период времени. Косвенные измерения дают оценку функциональных возможностей, показателей качества программного продукта (надежность, эффективность, пригодность к сопровождению и т.п.).

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

Вторая классификация метрик - классификация по признаку их ориентации:

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

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

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

Размерно-ориентированные метрики

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках (Lines Of Code). LOC-оценка - это количество строк в программном продукте. Принято регистрировать следующие показатели:

- общие затраты (в человеко-месяцах - чел.-мес);

- объем программного изделия (в тысячах строк исходного кода -KLOC);

- стоимость разработки (в тыс.рублей или в долларах $);

- объем документации (в страницах документов -СД);

- ошибки, обнаруженные в течение первого года эксплуатации (число ошибок - ЧО);

- число людей, работавших над изделием (человек);

- срок разработки (в календарных месяцах).

На основе перечисленных показателей вычисляются размерно-ориентированные метрики производительности и качества (для каждого проекта):

Достоинства размерно-ориентированных метрик:

1) широко распространены;

2) просты и легко вычисляются.

Недостатки размерно-ориентированных метрик:

1) зависимы от языка программирования;

2) требуют исходных данных, которые трудно получить на начальной стадии проекта;

3) не приспособлены к непроцедурным языкам программирования.

Функционально-ориентированные метрики

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

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

2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.

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

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

Количество функциональных указателей вычисляется по формуле

После вычисления FP на его основе формируются метрики производительности, качества и т. д.:

Область применения метода функциональных указателей - коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО. ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика - количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов: обработка прерываний, инвертирование матрицы, расшифровка битовой строки. Для формирования указателя свойств составляется табл. 6.

Достоинства функционально-ориентированных метрик:

1. Не зависят от языка программирования.

2. Легко вычисляются на любой стадии проекта.

Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.

FP-оценки легко пересчитать в LOC-оценки. Результаты пересчета зависят от языка программирования, используемого для реализации ПО.

Цель этой деятельности - сформировать предварительные оценки, которые позволят:

- предъявить заказчику корректные требования по стоимости и затратам на разработку программного продукта;

- составить план программного проекта.

При выполнении оценки возможны два варианта использования LOC- и FP-данных:

- в качестве оценочных переменных, определяющих размер каждого элемента продукта;

- в качестве метрик, собранных за прошлые проекты и входящих в метрический базис фирмы.

Порядок проведения процедуры оценки.

1. Область назначения проектируемого продукта разбивается на ряд функций, каждую из которых можно оценить индивидуально: f1 , f2 ,..., fn.

2. Для каждой функции fi планировщик формирует лучшую LOCлучшi(FPлучшi), худшую LOCхудшi(FPхудшi) и вероятную оценку LOCвер i(FPвер i). Используются опытные данные (из метрического базиса) или интуиция. Диапазон значения оценок соответствует степени предусмотренной неопределенности.

3. Для каждой функции fi в соответствии с -распределением вычисляется ожидаемое значение LOC- (или FP-) оценки:

4. Определяется значение LOC- или FP-производительности разработки функции. Используется один из трех подходов:

а) для всех функции принимается одна и та же метрика средней производительности ПРОИЗВср, взятая из метрического базиса;

б) для i-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

,где LOCcp - средняя LOC-оценка, взятая из метрического базиса (соответствует средней производительности);

в) для i-й функции настраиваемая величина производительности вычисляется по аналогу, взятому из метрического базиса: ,

Первый подход обеспечивает минимальную точность (при максимальной простоте вычислений), а третий подход - максимальную точность (при максимальной сложности вычислений).

5. Вычисляется общая оценка затрат на проект

Современные крупные проекты ИС характеризуются, как правило, следующими особенностями:

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

- наличие совокупности тесно взаимодействующих компонентов (подсистем), имеющих свои локальные задачи и цели функционирования (например, традиционных приложений, связанных с обработкой транзакций и решением регламентных задач, и приложений аналитической обработки (поддержки принятия решений), использующих нерегламентированные запросы к данным большого объема);

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

- необходимость интеграции существующих и вновь разрабатываемых приложений;

- функционирование в неоднородной среде на нескольких аппаратных платформах;

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

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

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

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

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

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

Понятно, что как состав, так и значимость ролей разработчиков и тех, кто с ними связан, различаются в зависимости от выполняемого проекта, от коллектива исполнителей, принятой технологии, от других факторов. Неоднозначность выбора ролей приводит к тому, что их список часто становится непомерно велик (иллюстрацией тому может служить первая редакция документации по Rational Unified Processing (RUP), в которой определено свыше 20 ролей; в последующих версиях документа это число сокращено до обозримого уровня [30]). Чрезмерное увеличение числа есть следствие отождествления роли и функции и, соответственно, игнорирования понятия родственности функций. В то же время, если ролей выбрано недостаточно, есть опасность, что не все нужные в проекте функции будут охвачены планированием и управлением.

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

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

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:

- принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

- DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Структурное проектирование позволяет одновременно сосредотачиваться на меньшем количестве деталей.

Нисходящее проектирование хорошо работает , когда проблема имеет ясно выраженный иерархический характер.

Минусы:

- Трудно поддерживать функциональную точку зрения

- Реальные системы трудно охарактеризовать функционально

- Теряется из виду данные

- Производится код, который плохо подходит для многократного использования

Сущность структурного подхода

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

Все наиболее распространенные методологии структурного подхода [9,11,12,13] базируются на ряде общих принципов [3]. В качестве двух базовых принципов используются следующие:

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

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие:

- принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечения от несущественных;

- принцип формализации - заключается в необходимости строгого методического подхода к решению проблемы;

- принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:

- SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);

- DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);

- ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Предложена Дугласом при работе над военными проектами.

На основе SADT разработана методика IDEF0 (для описания предметной области) комитетом ICAM.

Модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.

Основные элементы методологии:

1. блочное моделирование:

- функции - это блоки

- интерфейсы входа/выхода - дуги (стрелки)

2. строгость и точность

Существует определенные правила SADT:

- количество блоков на диаграмме 3-6

- связанность диаграмм (номера блоков)

- уникальность наименования (повторений не д.б.)

- синтаксические правила для блоков и дуг

- разделение входов и управлений

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

SADT может использоваться для анализа функций существующих организаций (реинжениринг бизнес-процессов), а также для последующей автоматизации.

Состав функциональной модели

Функция - это действие; формулируется в виде глагола в неопред. Форме, либо - отглагольного сущго.

Вход - это информация/ресурсы, подлежащие преобразованию

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

Выход - это результат выполнения функции (есть всегда): запросы на ресурсы от других бизнес-процессов, предложение ресурсов, поставка ресурсов под конкретный бизнес-процесс.

Механизм(инструмент) - это всегда изнашиваемый ( устаревающий) ресурс: исполнители функций (человек, автоматизированная система) и вспомогательные инструменты (значимые (токарь - станок )).

Признак блокировки

По признаку блокировки ресурсы делятся на:

1. ресурсы, которые не блокируются - ресурсы общего пользования

2. блокируемые - может использоваться только одной функцией в один момент времени (пр.: входы и инструменты).

Иерархия диаграмм

1. контекстная диаграмма

название блока - название всех модели

на диаграмме д.б.:

цель составления работы

точка зрения - должность человека (как min), который строит данную диаграмму, либо со слов которого строится

2. далее след. диаграмма (главная в контекстной диаграмме)

Типы связей между функциями

Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания:

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

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

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

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

4 блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные

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

6 Диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой

Значимость Тип связности Для функций Для данных

0 Случайная Случайная Случайная

1 Логическая Функции одного и того же множества или типа (например, "редактировать все входы") Данные одного и того же множества или типа

2 Временная Функции одного и того же периода времени (например, "операции инициализации") Данные, используемые в каком-либо временном интервале

3 Процедурная Функции, работающие в одной и той же фазе или итерации (например, "первый проход компилятора") Данные, используемые во время одной и той же фазы или итерации

4 Коммуникационнная Функции, использующие одни и те же данные Данные, на которые воздействует одна и та же деятельность

5 Последовательная Функции, выполняющие последовательные преобразования одних и тех же данных Данные, преобразуемые последовательными функциями

6 Функциональная Функции, объединяемые для выполнения одной функции Данные, связанные с одной функцией

Глоссарий

Для каждого элемента IDEF0 существует описание. Все использованное хранится в глоссарии.

Принципы ограничения сложности IDEF0

- Количество функциональных блоков 3-6

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

Ее основой послужила диаграмма Гейна-Сарсона.

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

Компоненты диаграммы:

1. внешняя сущность

2. системы и подсистемы

3. процесс

4. накопители данных

5. потоки данных

Внешняя сущность

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

Пр.: заказчик, клиент, поставщик

Системы и подсистемы(С/ПС)

Сложная ИС всегда декомпозируется на ряд ПС.

Поле имени формулируется в виде подлежащего и дополнения (нет глаголов)

Процессы

Процессы определяют преобразование входных потоков данных в выходные

Физически это: отдел организации, автоматизированная система, аппаратное устройство и т.д.

Пр. поля физич. реализации: 1С-бухгалтерия

Накопители данных

Это абстрактное устройство для хранения данных.

Информацию в этом устройстве можно хранить, извлекать и вкладывать в накопитель.

Накопитель данных физически это:

- Ящик в картотеке

- Файл на магнитном носителе, Таблица в бД и т.д.

Накопитель данных для проектировщика является прообразом будущей БД.

Потоки данных

Информация, передаваемая ч/з некоторое соединение от источника к приемнику.

Каждый поток данных должен иметь имя.

Построение иерархии диаграмм потоков данных

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

Правила детализации:

a. Правило балансировки

На детализирующей диаграмме внешние источники/приемники данных - это

только те компоненты, которые присутствуют на родительской диаграмме.

b. Правило нумерации - иерархическая нумерация.

Миниспецификация - это описание логики процесса.

Должна формулировать основные функции таким образом, чтобы специалист, выполняющий реализацию проекта, смог их выполнить или написать программу. Обычно состоит из 20-30 строк.

Для создания миниспецификации у DFD д.б. не более 2-3 потоков, описание которых не более 30 строк.

Case-метод Баркера

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

Наиболее распространенные средства моделирования:

- ER-диаграммы П.Чен

Используются для проектирования реляционных БД

- Метод Баркера - развитие ER-Diagram

Поянтия метода Баркера:

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

Свойства сущности:

- Имеет уникальное имя

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

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

Связь - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

# - ключевой атрибут

Супертипы и подтипы

В методе Баркера подтип рисуется внутри супертипа.

Супер-тип - это сущность, которая является обобщенным понятием для группы подобных сущностей.

Взаимоисключающие связи

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

Рекурсивная связь

Сущность связана сама с собой.

Неперемещаемая связь - экземпляр сущности не м.б. перемещен из одного экземпляра связи в другой.

Методология IDEF1

Разработал Т.Рэмей. Основана на подходе Чена. Пакеты Erwin Design/IDEF (IDEF1X).

Зависимая сущность - с закругленными углами, независимая - с прямыми.

Со стороны потомка ставится тоска у связи. Арибут, который наследуется от родителя обозначается (FK) - внешний ключ.

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

- Функциональную точку зрения трудно развивать.

- Реальные системы трудно охарактеризовать функционально.

- Фокусирование на функциональности теряет из виду данные.

- Функциональная ориентация производит код, менее пригодный для многократного использования.

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

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

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

Объектно-ориентированное проектирование - конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных.

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

Объектно-ориентированные методы лучше потому что:

- Они работают на более высоком уровне абстракции.

- Нет "прыжков" между фазами.

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

- Они поощряют и поддерживают классические достоинства хорошего программирования и проектирования.

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

Объектно-ориентированный подход имеет два аспекта:

- объектно-ориентированная разработка программного обеспечения;

- объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированная разработка программ

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. Говоря об объектно-ориентированной разработке, имеются в виду:

- объектно-ориентированные технологии разработки программных систем;

- инструментальные средства, поддерживающие эти технологии.

Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.

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

Различные объектно-ориентированные методологии разработки программного обеспечения:

- RUP (Rational Unified Process)

- OMT (Object Modeling Technique)

- SA/SD (Structured Analysis/Structured Design);

- JSD (Jackson Structured Development);

- OSA (Object-Oriented System Analysis)

Объектно-ориентированная разработка программного обеспечения связана с применением объектно-ориентированных моделей при разработке программных систем и их компонентов. Говоря об объектно-ориентированной разработке, имеются в виду:

- объектно-ориентированные технологии разработки программных систем;

- инструментальные средства, поддерживающие эти технологии.

Объектно-ориентированная разработка может начаться на самом первом этапе жизненного цикла; она не связана с языком программирования, на котором предполагается реализовать разрабатываемую программную систему: этот язык может и не быть объектно-ориентированным.

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

Различные объектно-ориентированные методологии разработки программного обеспечения:

- RUP (Rational Unified Process)

- OMT (Object Modeling Technique)

- SA/SD (Structured Analysis/Structured Design);

- JSD (Jackson Structured Development);

- OSA (Object-Oriented System Analysis)

Объектно-ориентированные языки программирования

Реализация программного обеспечения связана с использованием одного из языков программирования. Наиболее удобными для реализации программных систем, разработанных в рамках объектно-ориентированного подхода, являются объектно-ориентированные языки программирования, хотя возможна реализация и на обычных (не объектно-ориентированных) языках (например, на языке C и на языке Fortran).

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

Первый объектно-ориентированный язык программирования Simula 67 был разработан в конце 60-х годов в Норвегии. Авторы этого языка очень точно угадали перспективы развития программирования: их язык намного опередил свое время. Однако современники (программисты 60-х годов) оказались не готовы воспринять ценности языка Simula 67, и он не выдержал конкуренции с другими языками программирования (прежде всего, с языком Fortran). Прохладному отношению к языку Simula 67 способствовало и то обстоятельство, что он был реализован как интерпретируемый (а не компилируемый) язык, что было совершенно неприемлемым в 60-е годы, так как интерпретация связана со снижением эффективности (скорости выполнения) программ.

Но достоинства языка Simula 67 были замечены некоторыми программистами, и в 70-е годы было разработано большое число экспериментальных объектно-ориентированных языков программирования: например, языки CLU, Alphard, Concurrent Pascal и др. Эти языки так и остались экспериментальными, но в результате их исследования были разработаны современные объектно-ориентированные языки программирования: C++, Smalltalk, Eiffel и др.

Наиболее распространенным объектно-ориентированным языком программирования безусловно является C++. Разработка новых объектно-ориентированных языков программирования продолжается. С 1995 года широко распространен новый объектно-ориентированный язык программирования Java, ориентированный на сети компьютеров и, прежде всего, на Internet.

В основе RUP лежат следующие основные принципы:

- Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

- Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).

- Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

- Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

- Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

- Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Жизненный цикл разработки

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

Основные принципы:

- Итерационный и инкрементальный подход

- Планирование и управление проектом на основе функциональных требований к системе use case -варианты использования.

- Построение системы на базе архитектуры ПО.

Структура жизненного цикла проекта

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

Полный жизненный цикл разработки продукта состоит из четырех фаз, каждая из которых включает в себя одну или несколько итераций:

Процессы и фазы жизненного цикла проекта

Результаты начальной стадии(Разработка ТЗ):

1. основные требования к проекту его характеристики и ограничения

2. начальная модель вариантов использования (готовность 10-20% от конечной диаграммы)

3. начальный словарь терминов

4. начальный бизнес-план (группы затрат)

5. план проекта, отражающий стадии и итерации, сроки их выключения

6. один или несколько прототипов

Стадия разработки (Разработка Технического проекта):

1. выполняется более детальный анализ предметной области и построение базовой архитектуры

2. устраняются более рискованные элементы проекта

Результаты стадии разработки:

1. модель вариантов использования (> 80%)

2. перечень доп. требований, включая нефункциональные (внешние характеристики: цвет, текстура и т.д.)

3. описание базовой архитектуры

4. работающий прототип

5. уточненный бизнес-план

6. план всего проекта, отражающий итерации и критерии оценки каждой итерации.

Базовая архитектура

- Модель предметной области (основа для формирования классов)

- Технологическая платформа (локальная, клиент-сервер, сервер и т.д.)

Стадия разработки занимает 1/5 часть продолжительности проекта.

Результаты конструирования(Создание системы):

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

Стадия ввода в действие(внедрение системы):

Передача готового продукта в распоряжение конечных пользователей.

Стадия включает:

1. Бета-тестирование (поиск ошибок пользователями)

2. Параллельное функционирование с существующей системой, которая подлежит замене

3. Конвертирование БД

4. Оптимизация производительности

5. Обучение пользователя и службы сопровождения

В основе RUP лежат следующие основные принципы:

- Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

- Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).

- Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

- Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

- Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

- Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Основные принципы:

- Итерационный и инкрементальный подход

- Планирование и управление проектом на основе функциональных требований к системе use case -варианты использования.

- Построение системы на базе архитектуры ПО.

Существует четыре элемента RUP с позиции статистического аспекта:

1. Роли

2. Виды деятельности

3. Рабочие продукты

4. Дисциплины

Роли - поведение и ответственность личности или группы. Один человек может играть несколько ролей.

Виды деятельности - activity - это единица выполняемой работы конкретного исполнителя. Должна сопровождаться набором руководств (guidelines) - методика выполнения логических операций.

Рабочие продукты (artifacts)

Ими м.б.: модель, план, документ, исходный код

Дисциплины - технологический процесс, который определяет последовательность действий, приводящую к получению значимого результата

Существует 6 основных дисциплин:

1. построение бизнес-модели

2. определение требований

3. анализ и проектирование

4. реализация

5. тестирование

6. развертывание

существует 3 вспомогательных дисциплины:

1. управление конфигурацией

2. управление проектом

3. создание инфраструктуры

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

Современные способы обеспечения качества базируются на Total Quality Management (TQM - управление качеством в целом). Основные черты TQM:

- Управление ресурсами

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

Идея качества в США/Европе - 60-е годы. В программирование идеи качества пришли в конце 60-х:

Разработка Программного продукта - это процесс обеспечения качества ПП.

Показатели качества:

1.1. корректность (правильность)

1.2. устойчивость

1.3. расширяемость

1.4. многократность использования

1.5. совместимость

1.6. эффективность

1.7. переносимость

1.8. поддержка целостности

1.9. легкость использования

2.1. верификация

2.2. читабельность кода

2.3. модульность

2.4. структурированность

2.5. документированность (кода)

Внутренние характеристики являются ключом и причиной внешних характеристик качества.

Корректность и устойчивость

Корректность - правильная обработка на правильных данных

Устойчивость - не только правильность, это способность обрабатывать ситуации незапланированные проектом.

Устойчивые системы терпят неудачу без потери критических данных, т.е. предусмотрены непредвиденные ситуации в коде.

Расширяемость

Это важнейшее свойство для больших проектов.

Принципы создания расширяемого ПО:

Простота проекта

Децентрализация - разбиение сложных проблем на малые

Управляемость и независимость фрагментов (модульное программирование)

Многократность и совместимость

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

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

- Время и энергия, сохраненные через многократное использование, могут применяться для улучшения других характеристик качества программы (например, корректности или устойчивости).

Совместимость - мера того, на сколько просто объединить различные программные изделия вместе для повторного применения.

Основы совместимости вытекают, как правило, из общих проектных решений.

Обеспечивается качество посредством использования прошлых усилий при формировании новых систем.

Capability Maturity Model - коммерческая сертификация. Разработана в университете Карнеги-Мелон "описывает принципы и практические решения, определяющие уровень качества процесса разработки программного обеспечения и призвана помочь организациям-производителям усовершенствовать процессы разработки эволюционным путем, превратив их из хаотических процессов в процессы со строгой дисциплиной" (http://www.sei.cmu.edu).

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

Ключевым понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, а решения зачастую просто импровизируются "на ходу" - то, что на современном языке называется творческим подходом, или искусством. В этом случае велика вероятность превышения бюджета или выхода за рамки сроков сдачи проекта, поэтому менеджеры и разработчики вынуждены заниматься только разрешением актуальных проблем, становясь тем самым заложниками собственного программного продукта. К сожалению, на данном этапе развития находится большинство компаний (по градации CMM этот уровень обозначается числом 1).

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

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

(1) Начальный уровень (initial level) - это основной стандарт. К данному уровню, как правило, относится любая компания, которой удалось получить заказ, разработать и передать заказчику программный продукт. Предприятия первого уровня не отличаются стабильностью разработок. Как правило, успех одного проекта не гарантирует успешность следующего. Для компаний данного уровня свойственны неравномерность процесса разработки - наличие авралов в работе. К этой категории можно отнести любую компанию, которая хоть как-то исполняет взятые на себя обязательства.

(2) Повторяемый уровень (repeatable level). Данному уровню соответствуют предприятия, обладающие определенными технологиями управления проектами. Планирование и управление в большинстве случаев основывается на имеющемся опыте. Как правило, в компании данного уровня уже выработаны внутренние стандарты и организованы специальные группы проверки качества.

(3) Определенный уровень (defined level). Уровень характеризуется наличием формального подхода к управлению (то есть описаны все типичные действия, необходимые для многократного повторения: роли участников, форматы документов, производимые действия и пр.). Для создания и поддержания подобного стандарта в актуальном состоянии в организации уже подготовлена специальная группа. Компания постоянно проводит специальные тренинги для повышения профессионального уровня своих сотрудников. Начиная с этого уровня организация перестает зависеть от личностных качеств конкретных разработчиков и не имеет тенденции скатываться на нижестоящие уровни. Абстрагирование от разработчиков обусловлено продуманным механизмом постановки задач и контроля исполнения.

(4) Управляемый уровень (managed level). Уровень, при котором устанавливаются количественные показатели качества.

(5) Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по совершенствованию рассчитаны не только на существующие процессы, но и на оценку эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное совершенствование существующих процессов, которое в идеале призвано способствовать предупреждению возможных ошибок или дефектов. Применяется механизм повторного использования компонентов от проекта к проекту, например шаблоны отчетов, форматы требований.

Вывод:

Первые три уровня - это в основном технологические требования.

4 и 5 - управленческие.

При разработке ПС создается большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.

Эту документацию можно разбить на две группы:

- Документы управления разработкой ПС.

- Документы, входящие в состав ПС.

Документы управления разработкой ПС (process documentation), протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами (managers) - лицами, управляющими разработкой. Эти документы могут быть следующих типов:

- Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения.

- Отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами.

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

- Рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС.

- Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.

Документы, входящие в состав ПС (product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) - во всяком случае они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:

- Пользовательская документация ПС (П-документация).

- Документация по сопровождению ПС (С-документация).

Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми руководствуется пользователь при инсталяции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда данное ПС взаимодействует с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.

В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС. Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования. Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.

Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано данное ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС [13.2]. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).

Можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:

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

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

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

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

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

Разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя (в противном случае это ПС, вообще, не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками ПС, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели. Кроме того, для обеспечения качества пользовательской документации разработан ряд стандартов (см. гл.1.), в которых предписывается порядок разработки этой документации, формулируются требования к каждому виду пользовательских документов и определяются их структура и содержание .

Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроена (сконструирована), и модернизацию его программ. Как уже отмечалось, сопровождение - это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, - с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Команда разработчиков-сопроводителей должна будет изучать эту документацию, чтобы понять строение и процесс разработки модернизируемого ПС, и внести в эту документацию необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.

Документация по сопровождению ПС можно разбить на две группы:

(1) документация, определяющая строение программ и структур данных ПС и технологию их разработки;

(2) документацию, помогающую вносить изменения в ПС.

Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:

- Внешнее описание ПС (Requirements document).

- Описание архитектуры ПС (description of the system architecture), включая внешнюю спецификацию каждой ее программы.

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

- Для каждого модуля - его спецификация и описание его строения (design description).

- Тексты модулей на выбранном языке программирования (program source code listings).

- Документы установления достоверности ПС (validation documents), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.

Документы установления достоверности ПС включают прежде всего документацию по тестированию (схема тестирования и описание комплекта тестов), но могут включать и результаты других видов проверки ПС, например, доказательства свойств программ.

Документация второй группы содержит

Руководство по сопровождению ПС (system maintenance guide), которое описывает известные проблемы вместе с ПС, описывает, какие части системы являются аппаратно- и программно-зависимыми, и как развитие ПС принято в расчет в его строении (конструкции).

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

ИТ-менеджеры часто забывают о влиянии человеческого фактора на решение технических задач. Не оставляйте без внимания членов проектной группы и возлагайте на них обоснованные надежды.

Руководство группой: задачи ИТ-менеджеров

Человеческий фактор - один из самых важных в управлении ИТ-проектами, но зачастую его игнорируют. Джон Макдоналд, глава компании MacDonald Dettwiler and Associates, в своем докладе "Искусство и наука системной инженерии в международном контексте", сделанном на симпозиуме Incose в 1998 году, заметил, что успех проекта напрямую связан с используемыми талантами, и, что более важно, способом, в соответствии с которым руководство использует эти таланты в проекте.

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

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

Человеческий фактор управления проектом

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

Задача n личностей

Сложность создания хорошей динамики группы частично объясняется тем, что число рабочих связей растет как полиномиальная функция числа людей в группе (см. рис. 1).

Рис. 1. Количество рабочих связей быстро увеличивается с ростом числа членов проектной группы

Высока вероятность того, что при увеличении количества человек многие связи будут неэффективными. Это объясняет закон Брукса:

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

Нельзя формировать группы, игнорируя личносиные отношения.

Подходы к управлению группами и руководству

Теория Х .Теория X утверждает, что такой подход необходим, поскольку большинство людей по своей природе не любит работу и будет стремиться избежать ее, если у них есть такая возможность. Однако менеджеры должны принуждать, контролировать, направлять сотрудников и угрожать им, чтобы получить от них максимальную отдачу. В конце концов, теория утверждает, что большинство людей предпочитают, чтобы им говорили, что следует делать и им не придется ничего решать самим.

Теория Y (МакГрегор)

Теория Y утверждает, что работа - естественная и приятная деятельность. Однако менеджерам могут сплотить свою группу, сформулировав четкие и необходимые цели. Согласно Теории Y, большинство людей, на самом деле, очень ответственны и не увиливают от работы, как то утверждает Теория X.

Менеджеру, действующему согласно Теории Y, просто нужно предоставить ресурсы, определить цели и больше не вмешиваться в работу группы

Теория Z

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

Теория Z предполагает наличие внутреннего механизма управления. Дополнительное воздействие оказывают культурные нормы конкретной корпорации. Японские компании известны своим коллективным принятием решений и ответственностью на всех уровнях компании.

Управление в соответствии с Теорией Z особое внимание уделяет многофункциональности всех сотрудников компании и отрицает специализацию.

Теория W

Для каждого проекта, согласно Теории W, следует создавать взаимовыгодные условия, формировать такой же процесс и производить взаимовыгодный продукт.

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

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

2. Формировать разумные надежды. Необходимо создавать разумные и взаимно осуществимые ожидания в каждом аспекте человеческих отношений.

3. Способствовать общению. Создать атмосферу, поддерживающую выигрышные для сотрудников условия

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

Заключение: из всех теорий наиболее подходит Теория W.