Организационные процессы жизненного цикла программных средств
Одним из наиболее известных примеров практической реализации подхода быстрой разработки ПО является "Экстремальное программирование" (Extreme Programming - XP) [10]. Этот метод предназначен для небольших компактных команд, нацеленных на получение как можно более высокого качества и продуктивности, и достигает этого посредством насыщенной, неформальной коммуникации, придания на персональном уровне особого значения умению и навыкам, дисциплине и пониманию, сводя к минимуму все промежуточные рабочие продукты
Экстремальный цикл
В основе экстремального программирования — очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта.
Предпосылкой для такого режима работы является многократно проверенный факт, что требования редко бывают полными, своевременными и корректными. Иными словами, как бы хорошо вы ни планировали свое приложение, имейте в виду, что его 100% придется переделывать. Более того, его, возможно, придется переделывать даже на завершающей стадии. Не откладывайте переделки на конец работы, делайте их регулярно.
Как следствие постоянно изменяющихся требований следует другой принцип — позднее принятие решений.
Позднее принятие решений
"Поздний анализ" означает "принимайте конкретные решения только тогда, когда это нужно". В большинстве случаев принятые на начальной стадии решения относительно кода приходилось отменять под влиянием новых требований или других обстоятельств. Не принимайте никаких решений по поводу кода, которого у вас еще нет,— тогда вы развяжете себе руки при реализации текущих задач. Как правило, многое из запланированного оказывается вообще не востребованным. Поэтому планировать кодирование полезно перед началом каждого цикла, но не "раз и навсегда".
С другой стороны, любая начатая часть работы, любая подсистема должна быть закончена прежде, чем начнется работа над другими секциями кода. Такая методика известна как кодирование в глубину.
Кодирование в глубину
Кодирование в глубину (по аналогии с названием метода обхода бинарного дерева) обозначает, что в течение цикла должна быть полностью разработана и протестирована отдельная функциональность и проигнорированы соседние с ней области. Подразумевается, что готовая часть будет включать прикладную логику, пользовательский интерфейс, документацию и набор тестовых заданий для демонстрации работоспособности. Те, кто писали документацию по давно завершенной системе, поймут, насколько это важно.
Легко также впасть в искушение — и вместо насущных и актуальных задач перейти к более отдаленным, но и более легким или удобным частям приложения. Это не правильно — таким образом нарушается принцип работоспособности приложения к концу цикла.
Из готовых, законченных функциональностей складываются истории пользователя, и именно "закрытие" отдельного класса проблем пользователя в самый быстрый срок должно стать основной целью. В противном случае может сложиться ситуация, когда на 90% готовое приложение нельзя показать заказчикам и пользователям, поскольку оно до конца не выполняет ни одной функции.
Помимо концентрации на одной задаче в каждом конкретном цикле важное значение имеют также скорость проекта и фактор загрузки.
Идеальный день разработчика и фактор загрузки
Важным первичным инструментом при расчетах является идеальный день разработчика — то есть день, когда разработчик полностью концентрируется на решении проблем проекта. Это тот срок, в который разработчик может выполнить заданный объем работы при максимальной загрузке. Но было бы большой ошибкой использовать разработчика в этом режиме без крайней необходимости. Ритм работы экстремального программирования отнюдь не экстремален — и даже не должен подходить к отметке "горячо", по крайней мере в начале разработки.
Фактор загрузки — это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки. Нормальными считаются факторы от двух до пяти, причем чем больший фактор вы можете позволить — тем больший запас адреналина есть в запасе у вашей команды. Опытные менеджеры используют "три" как стартовое значение, но для новых неосвоенных технологий следует использовать четыре или пять.
Другим временным фактором является скорость проекта.
Скорость проекта
Скорость проекта — это скорость реализации частей программы, определенных для заданного цикла. В качестве основных ориентиров прогресса в разработке выступают реализации историй пользователей.
История пользователей
История пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". В отличие от глобальных Use Case, где рассматриваются целые классы пользователей, историю пользователя легко определить, спланировать на конкретный цикл и реализовать в определенный срок. Скажем, "ввод накладной" значительно более ясен и детерминирован, чем "обработка входных документов".
Истории пользователей до последнего момента не принимают детального вида, в духе позднего принятия решений. Реализация истории должна быть ограничена по срокам от одной до трех недель разработки — в противном случае такая история должна быть разбита на более мелкие. Главное — избежать ситуации, когда нечто достаточно долго делается без обратной связи, поскольку все сделанное потенциально является предметом критики и переработки.
План релиза
План релиза, утверждаемый на специальном совещании, дает точный ответ на вопрос, какие именно истории пользователей будут реализованы в данном релизе. Преимущество отдается небольшим инкрементальным релизам. Выбранные к реализации истории транслируются в конкретные задания программирования, такие как создание формы ввода или процедуры запроса к БД. Обычно после нескольких итераций оценки необходимых операций осуществляются очень точно. Как только план выполнения итераций выходит из-под контроля и, по крайней мере, после каждых нескольких удачных итераций повторно собираются совещания по поводу нового плана релиза.
Выбранные истории являются основой для планов итераций.
План итераций
План итераций ограничивает количество заданий, которые будут выполняться в данной итерации. Выборка производится на основании текущей скорости проекта, то есть на основе оценки идеального срока, умноженного на фактор загрузки. Истории пользователей получают приоритеты внутри цикла и трансформируются в задачи разработки, каждая из которых выполняется в течении одного-трех идеальных рабочих дней.
Если в результате детализации ожидаемое время разработки превосходит время цикла, то некоторые истории переносятся на более поздний срок. Этот эффект снежного кома — вполне обычная практика, поскольку детальные задачи часто распадаются на отдельные части, когда сумма времени для каждой превосходит время для целого.
Не стоит искать виновных в этой ситуации. Такое свойство планирования, как недооценка деталей, это и есть та причина, по которой не производится предварительное планирование. Детальный предварительный план всегда будет пересмотрен в будущем, и поэтому изначально и гарантированно нереален. Планирование производится только на основании предыдущего цикла, с коррекцией скорости проекта и с учетом перенесенных заданий.
Параллельно с выборкой историй пользователей план предусматривает создание набора тестов приемки, которые будут сопровождать код в процессе всех последующих сборок.
Тесты приемки
Тесты приемки создаются на основании историй пользователей и желательно до, а не после создания программных модулей. Без прохождения тестов история не может считаться реализованной ни в какой мере. Фактически, тесты приемки — это те же истории пользователей, но умноженные на возможные ошибки ввода и другие варианты поведения системы, то есть рассматриваются различные варианты конкретной истории. Естественно, что для многократного тестирования необходимо создать автоматические процедуры, вводящие тестовые наборы и ведущие журналы тестов.
Тестирование — не приложение к приложению, а, скорее, наоборот. Часто контроль качества (QA) и составление тестов возлагается на отдельную группу, в состав которой входят представители заказчиков.
Представители заказчиков
Представители заказчиков являются важнейшим звеном успешной разработки по технологии XP. Представители должны не просто контактировать, но буквально физически присутствовать в непосредственной близости и работать в команде разработчиков. Любая проблема должна быть обнаружена на самом раннем этапе, любые пожелания или вопросы должны решаться в реальном времени. Представители заказчика являются источником историй пользователей и тестовых наборов данных, они принимают участие в планировании плана релизов. Кроме того, открытый процесс позволяет инспектировать спорные участки кода в любой момент времени, создавая полностью прозрачную атмосферу между разработчиками и заказчиками.
Хотя это не очевидно, но практически происходит экономия времени заказчика, который все время находится в курсе дел — дополнительно время экономится на детальных спецификациях в начале работы, поскольку любой аспект можно выяснить в процессе работы. Впоследствии не придется инструктировать персонал заказчика, поскольку заказчик уже располагает высококачественными специалистами по данному продукту.
При этом многие документы-посредники становятся ненужными, поскольку многое решается устно, без вовлечения технических и бюрократических механизмов. Значение имеют только конечные результаты работы — но не промежуточные решения и дискуссии, так что нет необходимости документировать все возможные ходы мысли и альтернативы.
Помимо тесного взаимодействия с заказчиками, особого внимания требует и структура группы разработчиков.
Структура группы разработчиков
Для быстрой разработки применяется особая методология организации работы, основанная на теории психологии малых групп. Основной принцип: все разработчики должны быть доступны друг для друга, как организационно, так и физически,— преимущественно желательно располагать группу в одной большой комнате. Структура в группе — одноранговая, то есть существует только профессиональный авторитет, но не административное деление. Доказано, что самая продуктивная обстановка — умеренный шум большой рабочей комнаты, тишина или музыкальное сопровождение дают худшие результаты.
Все производственные вопросы решаются в самой группе, включая используемые методы, инструменты или технологии — эти параметры решения задачи не могут быть навязаны извне: как правило, профессионалы в коллективе решают поставленные задачи оптимально. Крое того, каждый разработчик самостоятельно выбирает подходящие задания, в зависимости от потребности группы и собственных способностей.
Одной из самых качественных технологий программирования на сегодня является парная технология, когда один программист вводит код, а другой при этом смотрит на экран и по ходу корректирует его или задает вопросы относительно реализации. Такая подстрочная критика кода, как показывает практика, в несколько раз повышает качество начального кода, сводя возможность ошибок в начальном коде к минимуму.
Второй принцип — принцип замены партнеров — означает, что пары меняют партнеров один-два раза в течение дня, причем группы работают над различными частями системы. Кажется, что такая метода не позволяет сконцентрироваться на отдельной области — однако практика опровергает это. Концентрация на одной области приводит к укоренению стиля, не всегда оптимального, а отсутствие критики кода может привести "хакера" к тяжело обнаружимым ошибкам. Постоянная смена области приложения, напротив, повышает не только квалификацию в результате обмена опытом, но также и мотивацию повышения собственного мастерства.
В обстановке групповой работы важное значение получает максимальная простота и эффективность используемого кода.
Простота и эффективность используемого кода
Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Например, любой разработчик должен уметь программно обрабатывать текстовые файлы, многие знают C++, Java, Perl, SQL и подобные инструменты. Использование редких технологий и инструментов, например сложных, особенно заказных RAD и т.п., может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта.
К сожалению, программный код, созданный по самым лучшим образцам, со временем имеет тенденцию к деградации под воздействием изменений и исправлений. Поэтому нужно взять за правило производить постоянный и бескорыстный рефракторинг.
Рефракторинг
Это наведение порядка в коде, переработка отдельных файлов и их групп с целью наведения порядка, удаления максимального количества ненужных фрагментов, объединения классов на основе схожей функциональности, коррекция комментариев, осмысленное переименование объектов и так далее. Рефракторинг должен стать лучшим отдыхом программиста в промежутке между решением сложных проблем. Не следует также забывать и о постоянном тестировании модулей.
Тестирование модулей
В отличие от тестов приемки, создаваемых заказчиками и отражающих истории пользователей, тестирование модулей — это сугубо технологическая проверка корректности классов на основании готовой или созданной специально для этих целей автоматизированной системы. Настоящая методика тестирования предусматривает создание сначала тестов и только после — самих классов, что исключает "подгонку" тестов к работающим прототипам и уклонение от острых ситуаций.
Классы-тесты должны быть неотъемлемой частью библиотеки или пакета, их отсутствие вызывает сомнения в работоспособности класса. Создаваемый для приложения код должен проходить все более сложные тесты — и таким образом изначально создаваться для некоторого реального окружения. Игнорирование этого принципа может усложнить тестирование впоследствии, когда уже трудно восстановить работу многих модулей.
Тесты служат четырем целям: во-первых, они, собственно, помогают протестировать функциональность; во-вторых, это естественная форма проектной документации, то есть на вопрос "что делает этот класс" можно ответить "пытается пройти набор функциональных тестов". Третье: тесты — это готовая часть описательной документации, сопровождающей класс после разработки, всегда отвечающая на вопрос "как использовать данный класс". И, наконец, это средство групповой разработки.
Выгода от написания модульных тестов хорошо проявляется в отношении группового авторства: фиксированный набор тестов, созданный модератором класса, всегда может гарантировать, что последующие изменения, произведенные другими членами команды, по-прежнему позволяют классу удовлетворять тестам.
Групповое авторство
Одной из проблем программирования является недоступность по той или иной причине разработчика определенного фрагмента кода, в результате чего его поддержка становится сложной или невозможной. Многие заказчики и группы попадали и попадают в зависимость от "гуру" — и всегда с негативными последствиями.
Архитектура программных систем. Классы архитектур программных средств, примеры.
Архитектура программных систем
Предварительные замечания
Для визуализации, специфицирования, конструирования и документирования программных систем необходимо рассматривать их с различных точек зрения. Все, кто имеет отношение к проекту: конечные пользователи, системные аналитики, руководители проекта, разработчики, тестеры, технические писатели, менеджеры и т.д. - преследуют собственные цели, и каждый смотрит на создаваемую систему по-разному в различные моменты ее жизненного цикла. При этом создаются самые разнообразные артефакты.
Системная архитектура является, возможно, наиболее важным артефактом, который используется для управления всевозможными точками зрения и тем самым способствует итеративной и инкрементной разработке системы на всем промежутке ее жизненного цикла. Раз уж мы ввели в использование эти два понятия, давайте дадим их точные определения, на сколько это возможно в таком предмете как программирование.
Итак, итеративным (iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий системы, причем каждая следующая версия усовершенствована по сравнению с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками (risk-driven), так как в при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума.
Теперь вернемся непосредственно к понятию архитектура. Под архитектурой программной системы понимается совокупность решений относительно:
организации программной системы;
выбора структурных элементов, составляющих систему и их интерфейсов;
поведения этих элементов, специфицированного в кооперациях с другими элементами;
составления из этих структурных и поведенческих элементов все более и более крупных подсистем;
архитектурного стиля, направляющего и определяющего всю организацию системы: статические и динамические элементы, их интерфейсы, кооперации и способы их объединения.
Архитектура программной системы охватывает не только ее структурные и поведенческие аспекты, но и использование, функциональность, производительность, гибкость, возможности повторного применения, полноту, экономические и технологические ограничения и компромиссы, а также эстетические вопросы.
Структурные сущности
Сущности являются основными элементами артефактов объектно-ориентированного анализа и проектирования. С их помощью можно создавать корректные артефакты. Структурные сущности - это имена существительные в предметной области, решаемой задачи. Как правило, они представляют собой статические части, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей.
Класс (class) - это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Класс реализует один или несколько интерфейсов.
Интерфейс (interface) - это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент. Интерфейс отвечает за видимое извне поведение элемента. С помощью интерфейса поведение класса или компонента может быть представлено полностью или частично, он определяет только спецификации операций (сигнатуры), но никогда - их практическую реализацию.
Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность ролей и других элементов, которые, работая вместе, производят некоторый кооперативный эффект, не сводящийся к обычно сумме слагаемых. Кооперация, таким образом, имеет как структурный, так и поведенческий аспект. Один и тот же класс может принимать участие в нескольких кооперациях, которые представляют собой реализацию образцов поведения, определяющих систему.
Прецедент (use case) - это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Основная цель применения прецедентов структурировать поведенческие сущности системы. Реализуются прецеденты посредством кооперации.
Три другие сущности: активные классы, компоненты и узлы - подобны классам, они описывают совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. Тем не менее, они в достаточной степени отличаются друг от друга и от классических классов и, учитывая их важность при моделировании определенных аспектов объектно-ориентированных систем, заслуживают персонального рассмотрения.
Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Активный класс практически полная копия обычного, за исключением того, что его объекты представляют собой элементы, деятельность которых осуществляется одновременно с деятельностью других элементов.
Два последних элемента: компоненты и узлы - также имеют свои особенности. Они соответствуют физическим сущностям системы, а предыдущие пять - концептуальным и логическим сущностям.
Компонент (component) - это физическая заменяемая часть системы, которая соответствует некоторому набору интерфейсов и обеспечивает его реализацию. В системе можно встретить различные виды устанавливаемых компонентов, классический пример тому компоненты COM+, а также компоненты, являющиеся артефактами процесса разработки, например файлы исходного кода. Компонент, обычно, представляет собой физическую упаковку логических объектов, таких как классы, интерфейсы и кооперации.
Узел (node) - это элемент реальной (физической) системы, который существует во время функционирования программного продукта и представляет собой некоторый вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью обработки. Совокупность компонентов может размещаться на узле, а также мигрировать с одного узла на другой.
Перечисленные семь базовых элементов: классы, интерфейсы, кооперации, прецеденты, активные классы, компоненты и узлы - являются основными структурными сущностями, которые могут быть использованы при создании артефактов объектно-ориентированного анализа и проектирования. Существуют и другие разновидности сущностей: актеры, сигналы, утилиты (виды классов), процессы и нити (виды активных классов), приложения, документы, файлы, библиотеки, страницы и таблицы (виды компонентов).
Кроме структурных, существуют и другие виды сущностей, но о них несколько позже.
Архитектурные виды
На сегодняшний день считается, что архитектура программной системы наиболее оптимально может быть описана с помощью пяти взаимосвязанных видов или представлений, каждый из которых является одной из возможных проекций организации и структуры системы и заостряет внимание на определенном аспекте ее функционирования:
вид с точки зрения прецедентов (use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестерами. Этот вид специфицирует не истинную организацию программной системы, а те движущие силы, от которых зависит формирование системной архитектуры;
вид с точки зрения проектирования (design view) охватывает классы, интерфейсы и кооперации, формирующие словарь задачи и ее решения. Этот вид подчеркивает прежде всего функциональные требования, предъявляемые к системе, то есть те услуги, которые она должна предоставлять конечным пользователям;
вид с точки зрения процессов (process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Этот вид описывает главным образом производительность, масштабируемость и пропускную способность системы.
вид с точки зрения реализации (implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Этот вид предназначен в первую очередь для управления конфигурацией версий системы, составляемых из независимых (до некоторой степени) компонентов и файлов, которые могут по-разному объединяться между собой;
вид с точки зрения развертывания (deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. В первую очередь он связан с распределением, поставкой и установкой частей, составляющий физическую систему.
Каждый из перечисленных видов может считаться вполне самостоятельным, так что члены группы проекта, могут сосредоточиться на изучении только тех аспектов архитектуры, которые непосредственно их касаются. Правда, нельзя забывать о том, что эти виды взаимодействуют друг с другом, что неудивительно, так как они представляют разные взгляды на одну систему. Например, узлы вида с точки зрения развертывания содержат компоненты, описанные для вида сточки зрения реализации, а те в свою очередь представляют физическое воплощение классов, интерфейсов, коопераций и активных классов из видов с точки зрения проектирования и процессов
14.Концепции и этапы архитектурного проектирования. Архитектурные модели.
Архитектура ПС - это его строение как оно видно (или должно быть видно) из-вне его, т.е. представление ПС как системы, состоящей из некоторой совокупности взаимодействующих подсистем. В качестве таких подсистем выступают обычно отдельные программы. Разработка архитектуры является первым этапом борьбы со сложностью ПС, на котором реализуется принцип выделения относительно независимых компонент.
Основные задачи разработки архитектуры ПС:
-выделение программных подсистем и отображение на них внешних функций (заданных во внешнем описании) ПС;
-определение способов взаимодействия между выделенными программными подсистемами.
С учетом принимаемых на этом этапе решений производится дальнейшая конкретизация и функциональных спецификаций.
Различают следующие основные классы архитектур программных средств:
1) цельная программа; 2) комплекс автономно выполняемых программ; 3)слоистая программная система; 4)коллектив параллельно выполняемых программ.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и ее реализация не представляется слишком сложной. Естественно, что такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутствия какого-либо внешнего взаимодействия программы, кроме как взаимодействия ее с пользователем, а последнее описывается в документации по применению ПС).
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
- любая из этих программ может быть активизирована (запущена) пользователем;
- при выполнении активизированной программы другие программы этого набора не могут быть активизированы до тех пор, пока не закончит выполнение активизированная программа;
- все программы этого набора применятся к одной и той же информационной среде.
Таким образом, программы этого набора по управлению никак не взаимодействуют - взаимодействие между ними осуществляется только через общую информационную среду.
Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
- на каждом слое ничего не известно о свойствах (и даже существовании) последующих (более высоких) слоев;
- каждый слой может взаимодействовать по управлению (обращаться к компонентам) с непосредственно предшествующим (более низким) слоем через заранее определенный интерфейс, ничего не зная о внутреннем строении всех предшествующих слоев;
- каждый слой располагает определенными ресурсами, которые он либо скрывает от других слоев, либо предоставляет непосредственно последующему слою (через указанный интерфейс) некоторые их абстракции. Таким образом, в слоистой программной системе каждый слой
может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
15. Процессы управления программным проектом. Планирование проекта.
Для проведения успешного проекта нужно понять объем предстоящих работ, возможный риск, требуемые ресурсы, предстоящие задачи, прокладываемые вехи, необходимые усилия (стоимость), план работ, которому желательно следовать. Руководство программным проектом обеспечивает такое понимание. Оно начинается перед технической работой, продолжается по мере развития ПО от идеи к реальности и достигает наивысшего уровня к концу работ.
Перед планированием проекта следует:
установить цели и проблемную область проекта;
обсудить альтернативные решения;
выявить технические и управленческие ограничения.
Планирование
Определяется набор проектных задач. Устанавливаются связи между задачами, оценивается сложность каждой задачи. Определяются людские и другие ресурсы. Создается сетевой график задач, проводится его временная разметка.
16.Управление рисками в процессе управления программным проектом.
На этой стадии исследуется область неопределенности, имеющаяся в наличии перед созданием программного продукта. Анализируется ее влияние на проект. Нет ли скрытых от внимания трудных технических проблем? Не станут ли изменения, проявившиеся в ходе проектирования, причиной недопустимого отставания по срокам? В результате принимается решение — выполнять проект или нет.
17.Оценка проекта на основе метрик. LOC-метрики и FP-метрики.
Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются размерно-ориентированные метрики на LOC-оценках (Lines Of Code). LOC-оценка — это количество строк в программном продукте.
Достоинства размерно-ориентированных метрик:
широко распространены;
просты и легко вычисляются.
Недостатки размерно-ориентированных метрик:
зависимы от языка программирования;
требуют исходных данных, которые трудно получить на начальной стадии проекта;
не приспособлены к непроцедурным языкам программирования.
Функционально-ориентированные (FP) метрики косвенно измеряют программный продукт и процесс его разработки. Вместо подсчета LOC-оценки при этом рассматривается не размер, а функциональность или полезность продукта.
Используется 5 информационных характеристик.
Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.
Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы — каждый учитывается отдельно.
Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом).
Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Область применения метода функциональных указателей — коммерческие информационные системы. Для продуктов с высокой алгоритмической сложностью используются метрики указателей свойств (Features Points). Они применимы к системному и инженерному ПО, ПО реального времени и встроенному ПО. Для вычисления указателя свойств добавляется одна характеристика — количество алгоритмов. Алгоритм здесь определяется как ограниченная подпрограмма вычислений, которая включается в общую компьютерную программу. Примеры алгоритмов; обработка прерываний, инвертирование матрицы, расшифровка битовой строки.
Достоинства функционально-ориентированных метрик:
Не зависят от языка программирования. 2.Легко вычисляются на любой стадии проекта.
Недостаток функционально-ориентированных метрик: результаты основаны на субъективных данных, используются не прямые, а косвенные измерения.FP-оценки легко пересчитать в LOC-оценки.
18. Классификация требований к программному обеспечению. Разработка требований.
Функциональные требования. Это перечень сервисов, которые должна выполнять система, причём должно быть указано, как система реагирует на те или иные входные данные, как она ведёт себя в определённых ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования. Описывают характеристики системы и её окружения, а не поведение системы. Здесь также может быть приведён перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и т.д.
Требования предметной области. Характеризуют ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и не функциональными.
Разработка требований - это процесс, включающий мероприятия, необходимые для создания и утверждения документа, содержащего спецификацию системных требований.
Различают четыре основных этапа процесса разработки требований:
- анализ технической осуществимости создания системы,
- формирование и анализ требований,
- специфицирование требований и создание соответствующей документации,
- аттестация этих требований
Проектирование пользовательских интерфейсов. Стили взаимодействия пользователя с системой.
страница 1страница 2страница 3
скачать
Другие похожие работы: