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

Размещено на http://www.allbest.ru/

Министерство образования и науки Кыргызской Республики

Кыргызский Национальный университет

IT-Колледж

Контрольная работа на тему: «Цели задачи технологий разработки программного обеспечения. Особенности современных крупных проектов»

По дисциплине: «Алгоритмизация и программирование»

Выполнил студент: Магдатов Белек Группа: ПИ-9-3-20

Проверил(а): Бегалиев С.А

Бишкек 2022



Оглавление

Введение

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

1. Классификация типов программного обеспечения

2. Жизненный цикл (ЖЦ) ПИ. Процессы ЖЦ ПИ

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

4. Измерения, меры и метрики. Размерно-ориентированные метрики. Функционально-ориентированные метрики

5. Качество программного продукта. Критерии качества ПО

6. Модели ЖЦ ПО. Инкрементальная модель. Содержание этапов создания ПИ

7. Проект. Состав и структура коллектива разработчиков, их функции



Введение

Программное обеспечение

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

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

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

Наиболее существенными признаками сложной системы является следующее:

-наличие общих задач

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

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

-иерархическая архитектура системы и иерархия критериев качества

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

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

-высокая надёжность системы в целом при абсолютной надёжности её компонентов



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

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

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

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

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



1. Классификация типов программного обеспечения

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

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

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

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

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

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

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



2. Жизненный цикл (ЖЦ) ПИ. Процессы ЖЦ ПИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Над данными стандартами работает 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 группы: метрики производительности, метрики качества продукции и технические характеристики продукта. Метрики производительности фокусируются на выходе процессов разработки ПО. Метрики качества позволяют судить о том, насколько близко соответствие программного изделия явным и подразумеваемым требованиям пользователя, т.е. пригодности изделия к использованию. Технические метрики в большей степени относятся к особенностям программного изделия, а не к процессу его разработки (например, логическая сложность изделия, модульность проекта и т.п.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Измерения, меры и метрики. Размерно-ориентированные метрики. Функционально-ориентированные метрики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Качество программного продукта. Критерии качества ПО

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

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

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

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

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

·

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

·

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

· Внешние

· Корректность (правильность)

· Устойчивость

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

· Многократность использования

· Совместимость

· Эффективность

· Переносимость

· Поддержка целостности

· Легкость использования

· Читабельность кода

· Модульность

· Структурированность

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. Модели ЖЦ ПО. Инкрементальная модель. Содержание этапов создания ПИ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Проект. Состав и структура коллектива разработчиков, их функции

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

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

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

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

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

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

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

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

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

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

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

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

Размещено на Allbest.ru

...