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

ГЛАВА 1

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

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

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

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

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

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

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

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

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

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

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

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

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

· Спецификацию желательного состояния бизнес-процесса.

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

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

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

· Функциональные требования к ПО – это описание того, что должна делать система; use case – это документированное описание последовательности действий в диалоге пользователя и системы с получением реального результата;

· Требования кданным ПО включают две компоненты: входныеивыходныеданные и данные, хранящиеся внутри системы на дисках;

· Требования к рабочим/эксплуатационным характеристикам или требования к функционированию, эксплуатационные требования, нормы и правила таким как: затраты на разработку; дата доставки ПО; время отклика/реакции на нажатие кнопки; объем данных, хранимых в системе; производительность системы; требования к надежности; требования по безопасности и т.д.

· Ограничения на разработку ПО;

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

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

Краткое[РА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] не только деморализует для пользователей и разработчиков, но часто массово дорогостоящим с точки зрения усилий, необходимых для устранения недостатков.

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

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

Пользователи[РА29] не знают (и обычно не заботятся) о тонкостями, в то время как инженер-программист ожидает, что подробные инструкции.

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

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

производство

Система[РА30] введена в эксплуатацию.

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

обслуживание

Когда[РА31] программное обеспечение используется, рано или поздно он будет почти наверняка нуждаются фиксации или усиления.

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

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

Документация

Документация[РА32] необходима для двух типов людей - пользователей и разработчиков.

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

Даже в компьютерный век, бумажные руководства по-прежнему приветствуются.

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

Документация[РА33] пользователя концентрируется на "что" (внешнее зрения) программного обеспечения, а не "как" (внутренняя работа).

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

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

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

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

Управление проектом

Кто[РА35] -то должен создавать и поддерживать планы, решать проблемы, распределять работу с людьми и проверить, что оно было завершено.

проектирование базы данных

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

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

Следовательно, мы не можем решить эту тему в рамках этой книги.

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

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

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

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

Именно на этом этапе были определены основные программные компоненты.

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

модели процессов

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

Существует явная необходимость быть организована при посадке на развитие.

Что вам нужно, когда вы устанавливаете о проекте программного обеспечения?

Тебе нужно:

· набор методов и инструментов;

· общий план или стратегию.

План[РА39] действий известен как модель процесса.

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

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

Как и любая модель, модель является лишь приближением к действительности.

Модель[РА40] процесса имеет два различных применений:

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

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

Есть[РА41] несколько моделей процессов основной:

· водопад

· прототипирования

· инкрементный

· проворный

· рациональное

· с открытым исходным кодом

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

Специальный[РА42] подход не планируется вообще, и ни одна организация не допустилf бы такого подхода.

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

Кроме того, разработка программного обеспечения является сложной задачей.

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

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

Методология

В[РА43] общем языке, методология слово означает изучение метода.

Он отвечает на такие вопросы, как: Что является основой метода х? Насколько хорош метод у?

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

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

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

Взлом

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

Есть на самом деле два типа хакера:

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

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

Это[РА45] второй из этих смыслов, которые мы будем использовать в этом разделе.

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

Тем не менее, дисплей мастерства также получает хакеров похвалы.

Хакеры также явно наслаждаются тем, что они делают, и смакуют свои навыки.

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

резюме

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

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

Модель процесса представляет собой стратегический план для полного процесса.

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

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

Методика является полным (часто фирменная) пакет методов, инструментов и нотации.

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

ГЛАВА 3

Введение

Эта[РА48] секция:

· объясняет, что происходит во время требований инженерии;

· объясняет характер спецификации требований;

· объясняет, как использовать случаи использования при определении требования;

· объясняет, как рисовать диаграммы прецедентов;

· предлагает руководящие принципы и контрольные списки для написания хорошего технические характеристики.

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

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

Когда инженеры имеют дело с требованиями, они

обычно называют системных аналитиков или, проще говоря, "аналитиков".

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

Что касается пользователей, то они иногда известны в качестве клиентов или клиентов.

Мы будем использовать термин "пользователь".

История[РА50] начинается, когда пользователь имеет идею для нового (или улучшенного качества) системы.

Он или она вызывает аналитиков, а затем они совместно работают над составлением спецификации требований.

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

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

Это, как правило, потребляет 33% усилий по разработке проекта.

Если мы не можем точно определить, что требуется, это бесполезно

реализовать его.

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

В реальном мире разработки программного обеспечения. Есть сильные

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

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

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

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

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

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

Стоимость фиксации ошибки во время тестирования может быть в 200 раз стоимости ее фиксации во время спецификации.

Предполагается, что-то вроде 50% ошибок возникают из

бедные спецификация.

Средство[РА54] , конечно, обнаружить (или предотвратить) ошибки рано,

есть, во время спецификации.

Легко писать плохие спецификации требований, предъявляемых к

программного обеспечения; трудно писать хорошие технические характеристики.

В этой главе мы рассмотрим принципы для написания

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

Помните, что спецификации обычно не пишется один раз

и затем замораживают.

Более типично, требования изменяются в течение программного обеспечения

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

Понятие требования

Задача[РА55] анализа и определения требований для системы

не является новым или свойственныйпрограммным обеспечением.

В течение нескольких поколений, инженеры проведения этих

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

Например, следующее является частью требований

спецификация для железнодорожного локомотива:

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

до 100 тонн на уклоне до 30% с ускорением

по меньшей мере, 30 км / ч / ч.

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

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

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

Он ничего не говорит о форме или механизмов колес.

Одна[РА57] из самых больших противоречий в вычислениях, является ли это

желательно (или даже возможно), чтобы указать, что система должна делать без учета того, как система будет делать это.

Это отношения между спецификацией и реализацией.

Теперь мы будем смотреть на обе стороны этого аргумента.

С[РА58] одной стороны, есть несколько причин, по которым требования

спецификация следует избегать вопросов осуществления.

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

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

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

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