Файл: Lektsii_TP.doc

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

ГОСТ 19.102-77 ( “стадии разработки”):

1. постановка задача (стадия “техническое задание”)

2. анализ требований, разработка, спецификация (стадия “эскизный проект”)

3. проектирование (“технический проект”)

4. реализация (“рабочий проект”)

Сопровождение – это процесс создания и внедрения нового продукта.

1.5. Эволюция моделей ЖЦ ПО

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

Рис.1.8.

Достоинства:

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

• простота планирования процесса разработки.

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

2. Модели с промежуточным контролем.

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

Рис.1.9.

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

3. Спиральная модель(середина 80-х)

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

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

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

1. сокращает время до появления первых версий программного продукта;

2. заинтересованность большого количества пользователей;

3. уменьшить вероятность морального устаревания системы.

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

1.6. Ускорение разработки ПО. Технология RAD

RAD– быстрая разработка приложений.

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

1. ведение разработки небольшими группами разработчиков (3-7 человек), каждый из которых реализует отдельные подсистемы проекта

2. использование итерационного полхода способствует уменьшению времени получения работоспособного прототипа

3. наличие четкого графика каждого цикла.

Процесс разработки:

1. анализ и планирование требований: формулирует наиболее приоритетные требования;

2. проектирование. Используя CASE–средства, детально описывают процессы системы; устанавливают требования разграничения доступа к данным; определяют состав документации. Для наиболее сложных процессов создают частичный прототип (экранную форму и диалог). По результатам анализа процессов определяют количество функциональных точек и принимают решения о количестве подсистем. Функциональная точка в технологииRAD– это любой из следующих функциональных элементов разрабатываемой системы:

а) входной элемент приложения (входной документ или экранная форма);

б) выходной элемент (экранная форма, документ и т.д.);

в) запрос (вопрос – ответ);

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

д) интерфейс приложения.

Нормы: меньше 1000 функциональных точек - достаточно одного человека;

от 1000-4000 – команда разработчиков (3 – 7 человек);

на каждые 4000 – команда.

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

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

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

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

1.7. Оценка качества процессов создания ПО.

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

1). Международные стандарты серии ISO9000 (9000-9004).

2) CMM(CapabilityMaturityModel) (модель совершенствования процессов создания ПО). Эту модель предложилSEI(SoftwareEngineeringInstitute).

3) Рабочая версия международного стандарта ISO/IEC15504. Эта версия более известна под названиемSPICE. (Определение возможностей улучшения процесса создания ПО).

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

2). CMM– это совокупность критериев оценки зрелости организации-разработчика и рецептов улучшения существующих процессов. ВCMMопределяют 5 уровней зрелости организаций-разработчиков:

• начальный (initiallevel). Он описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятиях такого уровня не существует стабильных условий для создания качественного ПО. Результат проекта полностью зависит от опыта программиста;

• повторяемый (repeating). На предприятии внедрены технологии управления проектами. Существуют стандарты на разрабатываемое ПО и группа обеспечения качества;

• определенный (defined). Стандартный процесс создания и сопровождения ПО полностью документирован;

• управляемый уровень (managed). В организации устанавливают количественные показатели качества на программные продукты и на процесс в целом.

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

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

2.1. Понятие технологичности программного обеспечения

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

2.2. Модули, их свойства.

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

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

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

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