2.3.4 Разработка тестов

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

Таблица1

№

Тип вклада

Код клиента

Менеджер

23

Пенсионный

232

Климов А.Р

62

Пенсионный

652

Климов А.Р

32

Потребительский

325

Карасева А.Н

Тест №1 и работа с таб.№1

Таблица№2

№	Код клиента	ФИО клиента	Адрес клиента	Остаток на счете
2	265	Гырбылев А.Н	Пр-Независимости7-913	357 645
7	648	Киселев Р.Д	ул. Лазо 25-103	2 562 000
9	325	Лысьева Л.В	ул. Мира 45-14	658 100

Тест №2 и работа с таблицей №2

2.3.5 Выбор языка программирования

1. Знание программиста.

2. Возможности программных средств языка.

3. Требование закащика.

3. Разработка проекта программного обеспечения.

3.1 Спецификация модулей

№	Название модулей	Назначения	Результат работы
1	Создание в таблице №1	Создание структуры в таблице№1 в ТК	Структура таблицы№1 в базе программного продукта
2	Ввод в таблицу№1	Ввод информации в таблицу№1	Заполненная таблица№1 в БД программного продукта
3	Управляющий модуль	Управление процессом подсчёта задач	Последующие взаимодействующий результат

3.2 Иерархическая система модулей

8

7

6

10

11

12

9

3

2

1

5

4

Контрольные вопросы

1. Какие этапы классического жизненного цикла вы знаете?

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

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

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

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

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

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Проектирование программного обеспечения состоит в создании представлений:

· архитектуры программного обеспечения;

· модульной структуры программного обеспечения;

· алгоритмической структуры программного обеспечения;

· структуры данных;

· входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

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

Цели изменений:

· исправление ошибок;

· адаптация к изменениям внешней среды программного обеспечения;

· усовершенствование программного обеспечения по требованиям заказчика.

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

Достоинства классического жизненного цикла:

· дает план и временной график по всем этапам проекта;

· упорядочивает ход конструирования.

Недостатки классического жизненного цикла:

· реальные проекты часто требуют отклонения от стандартной последовательности шагов;

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

· результаты проекта доступны заказчику только в конце работы.

2. Какими качественными характеристиками должен обладать программный продукт?

Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям; весь объем признаков и характеристик программ, который относится к их способности удовлетворять установленным или предполагаемым потребностям.

Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность — степень логического разбиения кода на ряд управляемых блоков. А также:

• Читаемость кода

• Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

• Низкая сложность кода

• Низкое использование ресурсов: памяти и процессорного времени

• Корректная обработка исключительных ситуаций

• Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

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

Некоторые из факторов качества:

понятность

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

полнота

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

краткость

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

портируемость

Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

согласованность

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

сопровождаемость

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

тестируемость

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

удобство использования

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

надёжность

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

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

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

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

безопасность

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

• Является ли пользовательский интерфейс интуитивно понятным?

• Насколько просто выполнять простые, частые операции?

• Насколько легко выполняются сложные операции?

• Выдаёт ли программа понятные сообщения об ошибках?

• Всегда ли программа ведёт себя так как ожидается?

• Имеется ли документация и насколько она полна?

• Является ли интерфейс пользователя само-описательным/само-документирующим?

• Всегда ли задержки с ответом программы являются приемлемыми?

3. Что такое связность модуля?

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

Существует 7 типов связности:

• Функциональная связность

• Последовательная связность

• Информационная связность

• Процедурная связность

• Временная связность

• Логическая связность

• Связность по совпадению

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

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

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

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

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

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

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

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

Мера связности	Сцепление	Модифицируемость	Понятность	Сопровождаемость
Функциональная	хорошее	хорошая	хорошая	хорошая
Последовательная	хорошее	хорошая	близкая к хорошей	хорошая
Информационная	среднее	средняя	средняя	средняя
Процедурная	приемлемое	приемлемая	приемлемая	плохая
Временная	плохое	Плохая	средняя	плохая
Логическая	плохое	Плохая	плохая	плохая
Случайная	плохое	Плохая	плохая	плохая

С понятием связность тесно связано понятие связанность или сцепление модулей

4. Что такое компонент? Чем он отличается от класса?

Литература

1. Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. – М.: Радио и связь, 1985.

2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами пользователя: Пер. с англ. – М.: ДМК, 2000.

3. Вендров Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. – М.: Радио и связь, 1985.

4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами А.М. Проектирование программного обеспечения экономических информационных сетей: Учебник. – М.: Финансы и статистика, 2000.

5. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори, 1996.

6. Козлинский А.В. CASE-технология: индустриальная разработка систем обработки информации – Soft Review // Компьютерное обозрение. – 1993. – октябрь.

7. Липаев В.В. Системное проектирование сложных программных средств для информационных систем. – М.: СИНТЕГ, 1999.

8. Маклаков С.В. BРwin и ERwin. CASE-средства разработки информационных систем. – М.: Диалог-МИФИ, 1999.

9. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. – М.: МетаТехнология, 1993.

10. Петров В.Н. Информационные системы. – СПб: Питер, 2002.

11. Малыгин М.П. «Базы данных: основы, проектирование, использование», «БХВ-Петербург» 2004 год

12. Глушаков С.В., Ломотько Д.В. «Базы данных», Киев «Абрис» 2000 год

13.Орлов С.А. «Технологии разработки программного обеспечения»,

учебное пособие, СПб.: Питер, 2002

Дополнительная литература

1. Атре Ш. «Структурный подход к организации баз данных». М.: «Финансы и статистика», 1983г.

2. Берещанский Д. Г. «Практическое программирование на dBase» М.: «Финансы и статистика», 1989г.

3. Диго С.М. «Проектирование и использование баз данных» М.: «Финансы и статистика», 1995г.

4. Дрибас В.П. «Реляционные модели баз данных» Мн.: Издательство БГУ, 1991г.

5. Нагао М., Катаяма С., Уэмура «Структуры базы данных». М.: «Мир», 1986г.

6. «Экономическая информатика» под редакцией Евдокимова В.В.: Санкт-Петербург, 1997г.