Функциональная спецификация программы это

Содержание

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

Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств ПС [3, 4, 5, 6], однозначно интерпретируемых разработчиками. Такие свойства мы будем называть примитивами качества ПС. Некоторые из примитивов могут использоваться по нескольким критериям. Ниже приводится зависимость критериев качества от примитивов качества ПС.

Надежность: завершенность, точность, автономность, устойчивость, защищенность.

2. Виды требований к программному обеспечению. Часть 1. (Курс бизнес-аналитик с нуля)

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

Эффективность: временнaя эффективность, эффективность по памяти, эффективность по устройствам.

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

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

Модифицируемость: расширяемость, структурированность, модульность.

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

Ниже даются определения используемых примитивов качества ПС [3, 4, 5].

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

Точность — мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.

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

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

Защищенность — свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.

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

Функциональные требования. Это документ или часть ТЗ

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

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

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

Эффективность по устройствам — мера, характеризующая экономичность использования устройств машины для решения поставленной задачи.

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

Понятность — свойство, характеризующее степень в которой ПС позволяет изучающему его лицу понять его назначение, сделанные допущения и ограничения, входные данные и результаты работы его программ, тексты этих программ и состояние их реализации. Этот примитив качества синтезирован нами из таких примитивов ИСО [4.4], как согласованность, самодокументированность, четкость и, собственно, понятность.

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

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

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

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

Независимость от устройств — свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях ЭВМ).

§Функциональная спецификация программного средства

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

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

Функциональная спецификация состоит из трех частей:

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

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

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

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

Источник: studfile.net

Технологии разработки программного обеспечения. Функциональная спецификация

1. Технологии разработки программного обеспечения

Составитель: Эверстов В.В.
Дата составления: 15/03/2016
Дата модификации: 15/03/2016

2. Что такое Функциональная спецификация?

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

3. Что такое Функциональная спецификация?

• Если техническое задание затрагивает все,
что касается отношений между заказчиком
и разработчиком, то спецификации – уже
внутренний документ. Внутренний, для
разработки.

4. Что такое Функциональная спецификация?

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

5. Что такое Функциональная спецификация?

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

6. Для чего она нужна?

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

7. Для чего она нужна?

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

8. Для чего она нужна?

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

9. Для чего она нужна?

• Распространена следующая ошибка:
разработчики долго обсуждают, каким
образом что-то должно быть реализовано, но
после этого никогда не принимают решение.
• Написание спецификации – прекрасный
способ точно выразить все эти раздражающие
вопросы разработки. Даже маленькие
решения могут быть выражены в
спецификации.

10. Что должно быть в функциональной спецификации?

Название,
Автор,
Общая информация,
Сценарии,
Детали,
Проблемы,
Заметки.

11. Что должно быть в функциональной спецификации?

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

12. Что должно быть в функциональной спецификации?

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

13. Что должно быть в функциональной спецификации?

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

14. Что должно быть в функциональной спецификации?

• Детали
– Детали наиболее важная часть функциональной
спецификации. В большинстве случаев программисты
решают, что некоторую детализацию они сделают
тогда, когда это понадобиться, а не сейчас.
Наипростейший способ построить детализацию это
описать каждое окно по отдельности. Можно каждому
окну давать свои имена. Очень важно здесь
рассмотреть все всевозможные ошибочные ситуации,
которые могут возникнуть в вашем продукте.
Необходимо, принять политику действий при
ошибочных ситуациях. И она должна быть описана в
функциональной спецификации.

15. Что должно быть в функциональной спецификации?

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

16. Кто должен писать функциональную спецификацию?

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

17. Кто должен писать функциональную спецификацию?

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

18. Обновления функциональной спецификации

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

19. Техническая спецификация

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

20. План работы

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

21. Для чего нужен план?

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

22. Что должно быть в плане?

• Минимально план должен включать:
–
–
–
–
Задачи,
Исполнителя,
Длительность реализации задачи,
Приоритет.
• Так же в нее можно включать:
–
–
–
–
Начальная оценка выполняемости,
Текущая оценка,
Прошло,
осталось

23. Кто его должен составлять?

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

24. Пример

Свойство
Задача
Приор
Нач Оцн
Тек Оцн
Прошл
о
Остало
сь
Проверка
орфографии
Добавить пункт
меню
1
12
8
8
0
Проверка
орфографии
Главный диалог
1
8
12
8
4
Проверка
орфографии
Словарь
2
4
4
4
0
Проверка грамматики
Добавить пункт
меню
1
16
16
0
16

25. Подсказки

• Каждое свойство должно состоять из нескольких
задач.
• Ставьте очень мелко дроблёные задачи.
• Добавьте строки для Праздников, Отпуска, и т.д.
• Поместите в план время отладки!
• Добавьте в план время на интеграцию.
• Добавьте буфер в план.
• Время выполнения задачи, которое вы
запланировали, лучше умножить на 3, тогда вы
получите более реальные сроки выполнения.

26. Анализ плана

• Если вы составили план, но оказывается,
что не успеваете в сроки, тогда надо
сделать одно из двух:
– Передвинуть сроки релиза,
– Убрать некоторые из свойств, передвинуть их
на следующие версии.
• Отслеживайте начальную и текущую
оценку.

27. GUI

28. Пользователь

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

29. Счастье

• Психологическая теория доктора Мартина Е. П.
Селигмана (Dr. Martin E.P. Seligman) под
названием «Приобретенная беспомощность»
(Learned Helplessness).
• Cостояние депрессии часто вырастает из
чувства беспомощности, когда человек
ощущает, что не может контролировать
происходящее.

30. Центральная аксиома

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

31. Центральная аксиома

• Суть пользовательского интерфейса в следующем:
реагирует ли пользовательский интерфейс так,
как пользователь того ожидает? Если нет,
пользователь будет ощущать собственную
беспомощность и невозможность контролировать
ситуацию,

32. Модель пользователя

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

33. Модель программы

• Программа тоже обладает моделью
поведения, которая, в отличие от модели
пользователя, закодирована в биты и
самым последовательным образом
выполняется CPU – модель программы, и
она есть — Закон. Если модель программы
соответствует модели пользователя, у нас
получился удачный пользовательский
интерфейс.

34. Как узнать ожидания пользователей?

• Спросите их!
• Выберите наугад 5 человек с работы, или
друзей, или родственников. Далее, задайте
пару вопросов и попробуйте составить
мнение об их модели пользователя.

35. Как узнать ожидания пользователей?

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

36. Сколько людей привлечь?

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

37. Как приспособить модель?

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

38. Вторая аксиома

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

39.

40. 41. Вторая аксиома

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

42. Метафоры

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

43.

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

44. Приглашения

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

45. Приглашения

• На некоторых дверях на уровне руки
расположены большие металлические пластины.
Единственное, что вы можете проделать с ними -толкнуть их.
• Как сказал Доналд Норман, они приглашают вас
толкнуть их. На других дверях вы увидите
большие закругленные ручки, которые просто
вынуждают вас потянуть за них. Они заранее
предполагают, как вам взяться за ручку, чтобы
удобно открыть дверь. Ручка приглашает вас
потянуть дверь на себя.

46. Приглашения

• Многие приложения в нижнем
правом углу имеют выпуклый
квадратик с тремя диагональными
линиями. Он приглашает вас
потянуть за него.

47. Постоянство дизайна

• То, что это делает Microsoft, не значит, что
это правильно», они создают
пользовательские интерфейсы,
неоправданно отличающиеся от того, к
которому люди привыкли.

48. Постоянство дизайна

• Так ли это на самом деле?
– Пусть это и неправильно, но если Microsoft использует
это в таких известных приложениях как Word, Excel, или
Internet Explorer, миллионы людей будут думать, что
это правильно, или, по крайней мере, является
стандартом.
– Microsoft тратит больше денег на тестирование usability
чем вы. Они ведут детальную статистику данных,
полученных на основе анализа миллионов звонков в
службу технической поддержки.

49. Примеры подражания

• Microsoft
• Amazon.com
• Adobe Photoshop

50. Чего не делают пользователи?

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

51. Не читают

52. Не дружат с мышью

• Иногда приходится пользоваться не самыми
оптимальными манипуляторами — трэкболами,
трэкпадами, и т.д.
• Иногда приходится пользоваться мышью не в
самых благоприятных условиях.
• Иногда человек, сидящий за компьютером –
новичок.
• Некоторые люди никогда не смогут развить эти
самые навыки, по разным причинам.
• Некоторые люди считают, что постоянное
применение мыши замедляет работу.

53. Выпадающие списки

54. Поля ввода

55. Не помнят ничего

56. Не помнят ничего

57. Пользователи – идиоты?

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

58. Как разработать хороший GUI?

• Планирование Деятельности.
– По методу Планирования Деятельности, вы сначала
описываете те виды деятельности, которые могут
заинтересовать пользователя. Достаточно
побеседовать с потенциальными пользователями, и вы
сможете составить такой список.
– Теперь, вместо того, чтобы рассуждать о программе как
программист («какие функции нужны для того, чтобы
сделать открытку»), вы думаете как пользователь:
какие действия он совершает,

59. ИТОГ

• Придумать воображаемых пользователей
• Продумать виды деятельности пользователей
• Узнать модель пользователя — как он будет
выполнять деятельность, основываясь на своем
опыте
• Сделать первый набросок дизайна
• Изменять дизайн, все больше и больше делая его
простым в использовании, до тех пор, пока
продукт не окажется в рамках способностей
воображаемых пользователей

Источник: ppt-online.org