Технические характеристики.

Автор: csaa ·

ГЛАВА 1

Структура выпускной квалификационной работы

Выпускная[РА1] квалификационная работа (ВКР) должна включать следующие результаты выполненных работ:

1) Наименование ВКР;

2) Спецификацию проблемы;

3) Спецификацию требований к ПО;

4) Техническую спецификацию ПО

5) Руководство программиста.

6) Руководство пользователя.

Описанная[РА2] структура ВКР – это перечень описаний результатов выполнения ВКР, а не содержание пояснительной записки в ВКР.

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

Спецификация проблемы

ВКР[РА3] должны содержать спецификацию проблемы, которая включает:

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

Спецификация требований к ПО

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

Функциональные требования к ПО – это описание того, что должна делать система; use case – это документированное описание последовательности действий в диалоге пользователя и системы с получением реального результата;
Требования кданным ПО включают две компоненты: входныеивыходныеданные и данные, хранящиеся внутри системы на дисках;
Требования к рабочим/эксплуатационным характеристикам или требования к функционированию, эксплуатационные требования, нормы и правила таким как: затраты на разработку; дата доставки ПО; время отклика/реакции на нажатие кнопки; объем данных, хранимых в системе; производительность системы; требования к надежности; требования по безопасности и т.д.
Ограничения на разработку ПО;
Целевые установки или указания, которых надо придерживаться при имплементации системы (целевые указания; руководящие указания; методические рекомендации; директива – официальные предложения и советы по поводу действий в определенной ситуации, для достижения определенной цели).

<p>Краткое техническое задание на ВКР

Краткое[РА4] техническое задание на ВКР необходимо разработать студенту 4-го курса и представить для утверждения темы ВКР заведующему кафедрой ПОКС до 1 марта 2017.

Это краткое ТЗ включает всего лишь три следующих структурных элемента ВКР:

1) Наименование ВКР;

2) Спецификация проблемы;

3) Функциональные требования к ПО в виде набора use cases.

Use Cases

Один широко используемый подход к документированию[РА5] требований является Use case. Эти текстовые описания, которые могут быть дополнены за счет использования UML диаграмм прецедентов. Прецеденты принимают точку зрения пользователя или пользователей системы. Пользователь, который осуществляет определенную роль называется актером. Прецедент задача актера нуждается в системе для выполнения.

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

Например,[РА6] в системе ATM, одна из вещей, что делает пользователь снимает наличные. Это случай использования. В рамках снятия наличных, пользователь должен будет выполнять подзадачи, например, предлагая свою карту и ввести ПИН-код.Приложение A.1: Банкомат:Банкомат имеет экран, устройство для чтения карт, маленький принтер, банкомат и клавиатуры. Клавиатура[РА7] имеет цифровые кнопки, клавишу ввода и кнопку сброса. На левой и правой части экрана расположены кнопки, которые позволяют выбрать любые настройки, отображаемые на экране. Банкомат подключен к банку через телефонную линию.Банкомат предоставляет средства для: · выдачи наличных денежных средств;· отображения текущего баланса. Пользователь[РА8] должен сначала преложить свою карту к считывателю. Дисплей затем просит пользователя ввести ПИН-код, с помощью клавиатуры. Если все прошло успешно, дисплей предоставляет набор опций. Система должна быть очень надежной, так как она должна использоваться необученным клиентов банка в публичных местах. Прецедент указывает то, что делает пользователь, и что делает система, но ничего не говорит о том, как система выполняет свои задачи. В системе ATM.Use Case для снятия наличныхc помощью банкомата:1) Пользователь предлагает свою карту.2) Система запрашивает PIN-код.3) Пользователь вводит PIN-код.4) Система проверяет PIN-код.5) Если карта и PIN действительны, система запрашивает у пользователя их выбора функции.6) Пользователь выбирает выдачу наличных средств.7) Пользователь запрашивает сумму.8) Пользователь вводит сумму.9) Система выталкивает карту.10) Когда пользователь отозвал карту, система распределяет денежные средства.[РА9]

Мы[РА10] видим, что задача пользователя требует целый ряд детальных шагов.

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

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

Другие use cases для банкомата проверки баланса и перевода денег.

Use Case для проверки баланса с помощью банкомата:

1) Пользователь предлагает свою карту.

2) Система запрашивает PIN-код.

3) Пользователь вводит PIN-код.

4) Система проверяет PIN-код.

5) Если карта и PIN действительны, система запрашивает у пользователя их выбора функции.

6) Пользователь выбирает проверить баланс.

7) Система отображает текущий баланс.[РА11]

Use[РА12] Case для передачи денег с помощью банкомата:

1) Пользователь предлагает свою карту.

2) Система запрашивает PIN-код.

3) Пользователь вводит PIN-код.

4) Система проверяет PIN-код.

5) Если карта и PIN действительны, система запрашивает у пользователя их выбора функции.

6) Пользователь выбирает передачу денег.

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

8) Пользователь вводит свой банковский счет.

9) Пользователь запрашивает сумму.

10) Пользователь вводит сумму.

11) Система выталкивает карту.

12) Когда пользователь отозвал карту, систему передачи денег.

Техническое задание на ВКР на примере банкомата (АТМ)

Рассмотрим краткое ТЗ на ВКР на примере ПО банкомата (АТМ).

Это краткое ТЗ включает всего лишь три следующих структурных элемента ВКР:

1) Наименование ВКР;

2) Спецификацию проблемы;

3) Функциональные требования к ПО в виде набора use cases.

Глоссарий

ГЛАВА 2

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

Эта[РА13] часть:

определяет деятельность в рамках разработки программного обеспечения;
объясняет идею модели процесса;
объясняет термин методологии;
объясняет термин хакерство.

Введение

В[РА14] этой части мы идентифицируем важные задачи разработки программного обеспечения.

Основная часть лекции описываются методы для выполнения этих задач.

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

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

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

Важными[РА15] 13 мероприятия, которые происходят в течение разработки программного обеспечения являются:

1) технико-экономическое обоснование;

2) разработка требований;

3) дизайн пользовательского интерфейса;

4) архитектурное проектирование;

5) детальное проектирование;

6) программирование;

7) системная интеграция;

8) валидация;

9) верификация (тестирование);

10) производство;

11) техническое обслуживание;

12) документация;

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

Модель[РА16] процесса представляет собой план, который предусматривает для всех этих необходимых 13 видов деятельности и стремится включать этапы методично.

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

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

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

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

Технико-экономическое обоснование.

Прежде[РА17] чем что-нибудь еще будет сделано, технико-экономическое обоснованиеустанавливает ли или нет проект, чтобы продолжить (технико-экономическое обоснование является одним из 13 важных необходимых мероприятий).

Может быть, что система не является необходимым, слишком дорогим или слишком рискованным.

Один из подходов к ТЭО для проведения анализа затрат и выгод.

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

Это сравнение затем определяет, идет ли проект вперед или нет.

требования к Инженеринг (спецификация)

В[РА18] начале проекта, разработчик обнаруживает, что пользователь (клиент или покупатель) хочет от программного обеспечения, и записывает требования как можно более четко.

Продукт этой стадии является спецификация требований.

Дизайн интерфейса пользователя

Большинство[РА19] программного обеспечения имеет графический пользовательский интерфейс, который должен быть тщательно спланирован таким образом, чтобы он был прост в использовании.

Архитектурный (крупномасштабные) дизайн

Система[РА20] программного обеспечения может быть большой и сложной. Иногда она слишком велика, чтобы быть записана в виде одной единственной программы.

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

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

Продукты деятельности являются архитектурные и проектные спецификации модуля.

Детальный дизайн

Конструкция[РА21] каждого модуля или компонента осуществляется. Продукты детальный дизайн каждого модуля.

Программирование (кодирование)

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

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

Системная интеграция

Отдельные[РА22] компоненты программного обеспечения объединены вместе, что иногда называют сборки.

Верификация

Это стремление гарантировать, что программное обеспечение является надежным.

По словам Барри Бoхем (один из всех времен великих людей программной инженерии), проверка дает ответ на вопрос: Мы правильно создаем программный продукт?

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

Верификация[РА23] связана с точки зрения разработчика — внутренней реализации системы.

Два типа верификации являются модульного тестирования и тестирования системы.

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

Входами модульного тестирования являются:

1) Блок спецификация;

2) Блок-код;

3) перечень ожидаемых результатов испытаний.

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

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

В[РА24] ходе тестирования системы или тестирования интеграции, модули связаны между собой и полная система испытана.

Входы системы тестирования являются спецификации системы и код для всей системы.

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

Валидация

Это[РА25] стремление к тому, что программное обеспечение удовлетворяет всем потребностям пользователей.

Согласно Бем, проверка дает ответ на вопрос: Мы строим равильный продукт?

Валидация делается с точкой зрения клиента системы, внешнего зрения системы.

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

Важным[РА26] примером деятельности валидации является приемо-сдаточных испытаний.

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

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

Результатом является то, что система соответствует требованиям клиента, либо его нет.

Текущие[РА27] данные свидетельствуют о том, что многие компьютерные системы не отвечают потребностям своих пользователей, и что поэтому успешная валидация является серьезной проблемой в разработке программного обеспечения на сегодняшний день.

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

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

Это[РА28] не только деморализует для пользователей и разработчиков, но часто массово дорогостоящим с точки зрения усилий, необходимых для устранения недостатков.

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

Это слишком легко добиться на стадии анализа потребности развития, когда у пользователей и разработчиков действительн