Требования к организации данных
Данные программы должны храниться в виде отдельных файлов.
Требования к временным характеристикам
Требования к временным характеристикам программы не предъявляются.
Требования к информационной и программной совместимости
Исходные коды программы должны быть реализованы на языке программирования C#.
Описание предметной области
Предметная область, которая реализуется в данной программной системе, включает в себя следующие понятия:
· Проект
· Участник
· Коммуникация
· Артефакт
· Журнал изменений
Проект имеет название, сроки, бюджет, в него вовлечено некоторое количество участников, в ходе разработки проекта создаются и изменяются артефакты, осуществляются коммуникации участников, в журнал проекта последовательно записываются события в рамках проекта.
Участник имеет ФИО, роль в проекте, привилегии, контактную информацию и идентификатор( для учета участия одних и тех же людей в разных проектах)
Коммуникация имеет тип, дату, продолжительность и место проведения.
Артефакт имеет название, тип, размер и версию
Журнал изменений хранит записи об изменениях названия, сроков, бюджета проекта, об изменениях артефактов, о добавлении и удалении артефактов, о совершении коммуникации между участниками, об изменениях личных данных и полномочий участников, а также записи об исключении участников из проекта. Записи в журнале производятся в том же порядке, в котором производились изменения в рамках проекта
Другие нефункциональные требования
◦ эффективность
◦ практичность
◦ сопровождаемость
◦ понятность
◦ простота использования
Требований мобильности и портируемости не предъявляется.
Разработка и описание программы
Итерация 1.
Анализ требований
Первая итерация включает в себя создание прототипа программы, который впоследствии послужит «ядром» программной системы.
На первой итерации разработки программной системы реализованы следующие функциональные характеристики:
· Создание нового проекта:
o определение значений стандартных атрибутов: «название», «сроки», «бюджет»;
o добавление участников в проект;
o добавление артефактов, созданных с целью реализации данного проекта;
· добавление ранее созданного проекта из файла;
· хранение данных о добавленных проектах;
· изменение вышеописанных свойств проекта;
· создание участников:
o определение значений стандартных атрибутов: «ФИО», «Роль», «Полномочия», «Контактная информация»;
· изменение информации об участнике;
· удаление участников из проекта;
· создание артефакта с указанием его вида, начального объема и версии;
· изменение объема и версии артефакта;
· сохранение истории изменений артефакта;
· удаление артефакта c историей его изменений;
· отображение всех созданных (добавленных) проектов
· отображение и анализ данных о проектах:
o отображение количества участников проекта;
o отображение количества артефактов;
o отображение истории изменений артефакта;
Требования, реализованные на первой итерации, представлены на диаграмме прецедентов (Рис 1).
Рис. 1
Проектирование
В процессе проектирования программной системы на первой итерации было выделено 4 класса:
· Project — соответствует проекту
· Artifact — соответствует артефакту
· Member — соответствует участнику
· Controller — отвечает за обработку запросов пользователя, сохранение данных о проекте
Шаблоны проектирования
На первой итерации был применен следующий шаблон проектирования
Шаблон проектирования Controller
Создан класс Controller, отвечающий за поступление и координацию операций, поступающих на уровне интерфейса пользователя. Формы делегируют получаемые сообщения о сохранении изменений объекта классу Controller
Описание классов
Класс Projectсодержит поля:
· Name – Название проекта
· Deadline – Срок сдачи проекта
· Budget – Бюджет проекта
· artifactList – Коллекция( список) артефактов проекта
· memberList – Коллекция( список) участников проекта
И следующий метод:
· ChangeProject – Изменение данных проекта
Класс Artifact содержит поля:
· Name – Название артефакта
· View – Вид артефакта
· Size – Размер артефакта
· Version – Версия артефакта
· artInfList – Коллекция( список) элементов типа структуры ArtifactInfo, хранит изменения всех артефактов
И следующие методы:
· Artifact – Конструктор класса
· ChangeArtifact – Изменение размера и версии артефакта
· CreateInfoList – Добавление изменения в коллекцию(список) изменений
Структура ArtifactInfo содержит 2 поля:
· newSize – Строка, содержащая размер артефакта
· newVersion - Строка, содержащая версию артефакта
Класс Member содержит поля:
· Surname – ФИО участника
· Role – Роль участника
· Priviligies – Привилегии участника
· ContactInformation – Контактная информация участника
И следующие методы:
· Member – Конструктор класса
· ChangeMember – Изменение данных участника
Также, в соответствии с шаблоном проектирования Controller, используется вспомогательный класс Controller, содержащий поля:
· PathList – Коллекция( список) путей к ранее созданным проектам
· ProjectDirAbsPath – Путь к текущему проекту
· ArtifactFileName – Имя файла, содержащего информацию об артефактах проекта
· ArtifactChangeFileName – Имя файла, содержащего информацию об изменениях артефактов проекта
· MemberFileName – Имя файла, содержащего информацию об участниках проекта
· project – Текущий проект
И следующие методы:
· ReadInfo – Чтение из файла путей к ранее созданным проектам
· ReadProjectFromFile – Считывание проекта из файла
· ReadArtifactFromFile – Считывание списка артефактов проекта из файла
· ReadMemberFromFile – Считывание списка участников проекта из файла
· ReadInfoListFromFile – Запись информации об изменении всех артефактов проекта в файл
· AddProject – Запись данных по текущему проекту в файл
· WriteArtifactToFile – Запись списка артефактов проекта в файл
· WriteMemberToFile – Запись списка участников проекта в файл
· AddInfoArtifact – Сохранение всех изменений артефакта проекта в файл
· SaveInfo – Сохранение путей к уже созданным проектам в файл
Диаграмма классов
Взаимодействие классов представлено в виде диаграммы классов (Рис. 2).
Рис.2
В структуру классаProject включены поля описывающие проект, а так же поля обеспечивающие взаимосвязь проекта и вовлеченных участников, информационного окружения (артефактов). Пользователю предоставлена возможность изменять основные поля проекта, поэтому в класс добавлен метод обновления этих данных.
Класс Member хранит основные данные об участниках и дает пользователю возможность изменять их с помощью метода ChangeMember.
Artifact хранит актуальные сведения об артефакте и историю его изменений. История представляет собой коллекцию (список) пар: размер - версия; заполненную в порядке изменения артефакта. Эти два поля объединены в структуру для удобства записи/чтения из файла. В дальнейшем будет создан класс, соответствующий журналу.
Управляющий класс Controllerобеспечивает мобильный доступ ко всем полям всех классов. Передается на все формы программной системы. Методы класса контроллер обеспечивают изменения текущего проекта в соответствии с запросами пользователя. Кроме того, они обеспечивают сохранение данных о проекте в файлы, а так же их чтение из файлов.
Диаграмма содержит все вышеописанные классы.
Между классами Project и Member — отношение композитного агрегирования «один ко многим». Решение установить такое отношение между классами было принято, так как в предметной области понятие участник подразумевает, что он вовлечен хотя бы в один проект, если человек является участником проекта, то он не может существовать самостоятельно. Проект в свою очередь может включать в себя много участников или ни одного( например, когда проект только разрабатывается, уточняются его бюджет, сроки и т.д)
Между классами Project и Artifact — отношение композитного агрегирования «один ко многим». Информационное окружение каждого проекта уникально — каждый артефакт принадлежит только одному проекту, при этом на некоторых этапах разработки артефактов может вообще не быть, а может быть и множество.
На первой итерации Project включен в состав Controller и выполняет функцию контейнера для временного хранения данных о проекте, в процессе изменения их пользователем. После окончания работы с проектом Controller сохраняет все данные о проекте в файл и очищает поля объекта класса Project. В системе объявлен только 1 объект типа Controller. Данная концепция была пересмотренна в последующих итерациях.
Программирование
На этапе программирования первой итерации были реализованы следующие задачи:
· Создание базового интерфейса.
· Программная реализация функциональных требований
· Описание вышеперечисленных классов и их взаимодействия на языке программирования
Для создания интерфейса использовался конструктор форм, встроенный в MS Visual Studio, описание полученного интерфейса приведено ниже.
Определение атрибутов проекта описано в его конструкторе, добавление и удаление участников и артефактов проекта осуществляется при помощи методов коллекции List.
Вся работа с файлами описана в методах класса Controller, которые вызываются при нажатии на кнопки форм.
Заполнение данных об артефакте и участнике происходит в конструкторах соответствующих классов. Их изменение реализовано в методах классов Atrifact и Member. При изменении артефакта инициируется вызов метода CreateInfoList класса Artifact, который заносит в список ArtInfList старые данные артефакта. Таким образом сохраняется история изменений.
Отображение всех созданных (добавленных) проектов, отображение количества участников проекта, отображение количества артефактов реализовано на главной форме проекта при помощи элемента DataGridView
Интерфейс
Интерфейс на первой итерации обеспечивает минимальный функционал программной системы, дает возможность взаимодействия с проектами. На первой итерации интерфейс создавался с целью предоставления разработчикам возможности тестирования описанных методов для последующей отладки программной системы, а так же адаптации программной системы к работе с ней пользователя.
Главная форма. Рис 3
 |
Отображается при запуске программы. Если ранее были добавлены проекты, то краткая информация о них будет представлена в таблице.
При нажатии на кнопку Open project пользователю предлагается выбрать файл ранее созданного проекта для его последующего редактирования.
При нажатии на кнопку пользователю предоставляется возможность выбрать директорию, куда будет сохранен новый проект, и заполнить данные о проекте
В обоих случаях появляется Form2(Рис. 4)
Форма работы с проектом. Рис 4
Поле Name — название проекта, Budget — его бюджет. Для выбора даты сдачи проекта пользователю предложено выбрать число на календаре.
Кнопка Add artifact — вызывает форму добавления артефакта, после его добавления, имя артефакта отображается в поле Artifacts.
Кнопка Add member — вызывает форму добавления участника, после его добавления, имя участника отображается в поле Members.
Кнопки Change member и Change artifact вызывают формы изменения участников и артефактов соответственно. На них предлагается выбрать элемент из уже созданных для его модификации.
При нажатии на кнопку View all artifact changes открывается окно со списком всех артефактов. При выборе одного из них отображаются все изменения данных о нем
Кнопка Save инициирует сохранение созданного/измененного проекта в файл
Кнопка Close закрывает окно и возвращает пользователя к главной форме
Тестирование и отладка
В процессе написания программы неоднократно производилось тестирование промежуточных версий. Использовалась стратегия черного ящика, выбор входных данных осуществлялся по принципу граничных зон. Вводились данные, которые потенциально могли привести к ошибкам в работе системы. Например, были рассмотрены следующие ситуации:
· Создание проекта, не содержащего ни одного участника
· Создание проекта, не содержащего ни одного артефакта
· Попытка сохранения проекта без указания имени/бюджета/сроков
· Открытие проекта из файла с последующим его изменением и сохранением
Найденные в процессе тестирования ошибки были успешно устранены, после чего было проведено повторное тестирование, показавшее корректную работу системы.
Итерация 2.
Анализ требований
Вторая итерация расширяет «ядро» программы. Формируется структура классов, которая обеспечит наличие в программе данных, необходимых для алгоритмов, которые будут добавлены на третьей итерации.
На второй итерации разработки программной системы добавлены следующие функциональные характеристики:
· добавление коммуникаций участников в рамках данного проекта
· задание состояния проекта: «разрабатывается», «просрочен»
· удаление проекта
· исключение участников из проекта с указанием причин
· отображение содержания выбранного проекта (его участников, истории их коммуникаций, артефактов проекта с указанием их актуальной версии и объема, истории изменения артефактов)
· отображение оставшегося времени до сдачи проекта
· отображение коммуникаций в рамках данного проекта
Проектирование
На этапе проектирования был разработан класс Journal и 7 структур, описывающих различные записи в журнале.
Введение этого класса и структур обеспечивает учет времени при моделировании работы над проектом.
Описание классов
Введены следующие изменения классов:
В класс Projectдобавлены следующие поля:
· MaxMemberID – Последний присвоенный Id участника проекта
· comList – Коллекция( список) коммуникаций проекта
· journal – Журнал изменений проекта
И следующий метод:
· AddMember ( ) – Добавление нового участника или участника из другого проекта (перегруженный метод)
В классе Artifact удалены следующие поля:
· artInfList – Коллекция( список) элементов типа структуры ArtifactInfo, хранит изменения всех артефактов
· LastChangeDate – использовалось для формирования artInfList
а также структура ArtifactInfo, так какизменения теперь хранятся в классе Journal.
И следующий метод:
· CreateInfoList – Добавление изменения в коллекцию (список) изменений
В класс Memberдобавлено следующее поле:
· Id – идентификационный номер участника
В классе Controller изменены следующие методы:
· ReadInfoListFromFile – удален, так как считывание информации об изменении всех артефактов проекта из файла теперь осуществляется в классе Journal.
· AddProject – переименован на WriteProjectToFile
· AddInfoArtifact ( ) – удален, так как сохранение всех изменений артефакта проекта в файл теперь осуществляется в классе Journal.
Добавлены следующие методы:
· SearchMember – Поиск участника по имени среди всех участников всех проектов
· ReadJournalFromFile – Считывание журнала проекта из файла
· SaveJuornal – Сохранение журнала проекта в файл
· WriteCommunicationToFile – Сохранение в файл всех коммуникаций проекта
· ReadCommunicationFromFile – Считывание коммуникаций проекта из файла
Созданы следующие классы:
Создан класс Communication содержащий поля:
· Type – Вид коммуникации проекта
· Date – Дата создания коммуникации проекта
· Lasting – Продолжительность коммуникации проекта
· Place – Место проведения коммуникации проекта
· ComMembList – Коллекция( список) участников коммуникации проекта
И следующие методы:
· Communications – Конструктор класса
· EndTime – Дата окончания коммуникации проекта
Создан класс Journal содержащий поля:
· CountOfRecords – Число записей журнала проекта
· changeProjList – Коллекция( список) элементов типа структуры ProjectChange, хранит изменения проекта
· changeArtList – Коллекция( список) элементов типа структуры ArtifactChange, хранит изменения артефактов проекта
· addArtList – Коллекция( список) элементов типа структуры ArtifactAdd, хранит данные о добавлении артефактов в проект
· deleteArtList – Коллекция( список) элементов типа структуры ArtifactDelete, хранит данные об удалении артефактов из проекта
· changeMembList – Коллекция( список) элементов типа структуры MemberChange, хранит изменения участников проекта
· deleteMembList – Коллекция( список) элементов типа структуры MemberDelete, хранит данные об удалении участников из проекта
· addCommList – Коллекция( список) элементов типа структуры CommunicationAdd, хранит данные о добавлении коммуникаций в проект
И следующие методы:
· AddRecord – Добавление записи в журнал (перегруженный метод)
Структура ProjectChange содержит поля:
· No – Номер записи
· chName – Изменившаяся характеристика проекта
· Description – Описание
Структура ArtifactChange содержит поля:
· No – Номер записи
· Name – Название артефакта
· View – Вид артефакта
· newSize – Размер артефакта
· newVersion – Версия артефакта
· Author – Автор изменения
· Description – Описание
Структура ArtifactAdd содержит поля:
· No – Номер записи
· Name – Название артефакта
· View – Вид артефакта
· newSize – Размер артефакта
· newVersion – Версия артефакта
· Author – Автор добавления
Структура DeletedArtifact содержит поля:
· No – Номер записи
· Name – Название артефакта
· View – Вид артефакта
· Reason – Причина удаления
Структура MemberChange содержит поля:
· No – Номер записи
· Name – Имя участника
· chName – Изменение
· Reason – Причина изменения
Структура ExcludedMember содержит поля:
· No – Номер записи
· Name – Имя участника
· Reason – Причина удаления
Структура MakeComm содержит поля:
· No – Номер записи
· Type – Вид коммуникации проекта
· Organizer – Организатор
· Purpose – Цель создания
Шаблоны проектирования
Шаблон проектирования Creator
Данный шаблон проектирования использовался при определении класса, отвечающего за создание объектов Member, Artifact, Communication, Journal. Таким классом был выбран Project, так как он агрегирует все вышеперечисленные объекты
Диаграмма классов
Взаимодействие классов представлено в виде диаграммы классов (Рис. 5).
Рис. 5
Journal актуальные сведения обо всех изменениях в рамках данного проекта и дает пользователю возможность в хронологическом порядке отслеживать эти изменения.
Communication хранит основные данные обо всех коммуникациях участников в рамках данного проекта.
Между Project и Communication — отношение композитного агрегирования «один ко многим». Конкретная коммуникация принадлежит только одному проекту, в проекте может быть много коммуникаций, при удалении проекта удаляются все коммуникации в его рамках.
Между Project и Journal — отношение композитного агрегирования «один к одному». Каждый журнал принадлежит только одному проекту, в проекте есть только один журнал, при удалении проекта удаляется журнал.
Между Controller и Project — отношение зависимости. В программной системе существует объект типа контроллер, который может получать для обработки списки из любого числа проектов
Между Communication и Member — отношение ассоциации «многие к более одного». Каждая коммуникация хранит в своих полях сведения о вовлеченных в нее участниках. В рамках проекта любой участник может участвовать в нескольких коммуникациях. Для создания коммуникации обязательно включить к нее как минимум двух участников.
Программирование
На этапе программирования второй итерации были реализованы следующие задачи:
· Расширение существующего интерфейса
· Программная реализация функциональных требований
· Описание разработанных на этапе проектирования классов и реализация их взаимодействия
В связи с появлением новых классов и возможностей увеличилось количество окон в системе и кнопок на них. Подробное описание в разделе интерфейс.
Для добавления коммуникаций к проекту в класс Project было включено поле comList – коллекция List из объектов типа Communication. Создание новой коммуникации осуществляется с помощью метода Add коллекции List, все данные о коммуникации задаются при вызове конструктора Communication.
Состояние проекта «разрабатывается», «просрочен» указывается в таблице с информацией о проектах на первой форме и форме работы с проектом(Рис 6). Состояние определяется из сегодняшней даты и сроков сдачи проекта. Если сегодняшняя дата больше чем дата сроков сдачи, проекту присваевается состояние просрочен.
Описано удаление проекта. Сведения о проекте удаляются из всей программной системы, также уничтожаются все файлы, хранящие данные о проекте.
Теперь при удалении участника из проекта в журнале фиксируется запись об исключении участника из проекта( запись типа ExcludedMember). На форме удаления участников добавлено поле Description для указания причин исключения.
Все данные о проекте пользователь может увидеть на главной форме и форме работы с проектом.
Интерфейс
Изменилась форма работы с проектом.
Кнопка Show Journal вызывает окно, на котором в элементе TextComboBox представлены все записи журнала в хронологическом порядке.
Добавлена кнопка Delete project, инициирующая удаление проекта.
Новый вид формы представлен на Рис. 6.
Форма работы с проектом. Рис. 6
Кнопка Communication служит для вызова окна создания коммуникации( Рис. 7).
Форма создания коммуникации. Рис. 7
В полях Type, Lasting, Place, Purpose пользователь задает тип коммуникации, ее продолжительность в часах, место проведения коммуникации и ее цели соответственно.
Дата, когда произошла коммуникация указывается также как и сроки сдачи проекта.
С помощью кнопки с изображением стрелки вправо из списка участников пользователь может добавить участников коммуникации.
Тестирование и отладка
В процессе разработки второго прототипа программы неоднократно тестировались промежуточные версии проекта. Серьезных ошибок выявлено не было, все обнаруженные мелкие ошибки были исправлены.
Примеры ошибок
| Симптомы ошибки | Условия возникновения | Гипотезы | Примечания |
| Программа выдала сообщение о том, что не найден проект, в то время как проекта с таким именем не должно быть в системе | У проекта изменялось название, производилось его сохранение в файл | В массиве, хранящем пути к сохраненным проектам остается запись со старым названием проекта. Во время прекращения работы программы в следствие этого сохранялся лишний путь | Единственная гипотеза оказалась верной, ошибка была устранена |
| При отображении содержимого журнала неверно указывались номера записей(1, 3, 6 вместо 1, 2, 3) | Совершение нескольких изменений в проекте и вызов окна отображения записей журнала | Из журнала исчезают записи при изменении проекта Ошибка в индексации при заполнении информационного поля | Ошибка действительно была в индексации. |
и т.д.
Поиск и исправление всех ошибок, возникающих в программе, не занимало более 20 минут.
Итерация 3.
Анализ требований
Заключительная итерация разработки. На ней реализуются все, указанные в расширенной постановке задачи требования к системе.
На третьей итерации разработки программной системы добавлены следующие функциональные возможности:
· отображение проектов, в которых задействован конкретный участник
· отображение артефактов, созданных/измененных участником
· отображение коммуникаций в рамках данного проекта
· отображение стоимости одного дня разработки проекта и сравнение с другими проектами
· расчет и представление соотношений количества артефактов, их суммарного объема, к времени разработки проекта, бюджету проекта
Проектирование
При разработке третьего прототипа программной системы крупных изменений архитектуры не произошло. Новых классов добавлено не было.
Описание классов
Класс Project:
В результате исправления ошибок, выявленных на этапе тестирования, исключено поле MaxID и перенесено в класс Controller.
Добавлен метод OneDayPay — рассчитывает стоимость одного дня разработки проекта.
Добавлен метод ArtCountPerDay — рассчитывает среднее количество артефактов, добавляемых в каждый день разработки.
Класс Artifact:
Исключено неиспользуемое теперь поле LastChangeDate
Класс Journal:
Добавлены методы AddByID и ChByID — возвращающие списки с названиями артефактов соответственно добавленных и измененных пользователем с заданным идентификатором.
Класс Controller:
Добавлен статический метод ConvertToUnixTimestamp — переводит данные из класса DateTime в секунды, используется для расчетов в методах OneDayPay и ArtCountPerDay класса Project, а также при заполнении колонки со временем разработки на главной форме.
Добавлен метод SearchProject — ищет в списке проектов ps проекты, в которых добавлен участник с идентификатором id
Диаграмма классов
Взаимодействие классов представлено в виде диаграммы классов (Рис. 8).
Рис. 8
В диаграмме классов учтены изменения указанные в описании классов. Отношения между классами остались прежними.
Программирование
На этапе программирования третьей итерации были реализованы следующие задачи:
o программная реализация расширенной функциональности
o улучшение интерфейса
Для отображение проектов, в которых задействован конкретный участник отображения артефактов, созданных/измененных участником была создана новая форма( Рис. 11, Рис. 12). Получение этой информации реализуется методами: SearchProject — класс Controller, AddByID и CnByID — класс Journal.
Отображение коммуникаций в рамках проекта добавлено на форму работы с проектом.
Стоимости одного дня разработки проектов, соотношения количества артефактов ко времени разработки указываются на главной форме в таблице.
Некоторые используемые в системе алгоритмы представлены в виде диаграмм:
Рис. 9 (Диаграмма деятельности: создание коммуникации)
Рис. 10 (Диаграмма последовательностей: сохранение проекта в файл)
Интерфейс
В программной системе появилось новое окно «Поиск по проектам» (Рис. 11)
Форма поиска по проектам. Ввод имени участника. Рис. 11
Пользователю предлагается ввести имя участника. При нажатии кнопки «Отобразить проекты участника», если существуют участники с таким именем, пользователь увидит информацию об их деятельности( Рис. 12)
Форма поиска по проектам. Отображение результата поиска. Рис. 12
Результаты поиска заносятся в поле слева. При выборе участника из поля заполняются информационные поля Состоит с следующих проектах, Добавленные артефакты, Измененные артефакты.
Кроме того все поля интерфейса программы теперь подписаны на русском языке.
Тестирование и отладка
В процессе разработки третьего прототипа системы неоднократно производилось тестирование отладка. В основном, применялась стратегия «белого ящика» для модульного тестирования программы. Тестовые наборы подбирались так, чтобы инициировать:
o выполнение всех операторов
o покрытие всех линий передачи управления
o прохождение всех путей от входа к выходу
Конечные и промежуточные результаты исполнения модулей отслеживались с помощью стандартных средств отладки интегрированной среды разработки( MS Visual Studio), проверки файлов, используемых программой.
Было проведено итоговое тестирование созданного продукта. Ввиду довольно больших размеров системы, для интеграционного тестирования была избрана стратегия «черного ящика», так как для проверки её с применением стратегии «белого ящика» потребовалось бы написание большого количества вспомогательного кода и времени. Результаты тестирования приведены в таблице:
| Метод | Тестовый набор(входные данные) | Тестовый набор(ожидаемый результат) | Результат | Примечания |
| Анализ граничных условий | При создании проекта в поле «Бюджет» введен символ $. | Вывод сообщения: «Введен недопустимый символ». | Соответствует ожидаемому | Тестовый набор из класса эквивалентности «Недопустимые входные данные» |
| Анализ граничных условий | Не заполнено ни одно информационное поле нового проекта. | При нажатии «Сохранить проект» вывод сообщения: «Не все поля заполнены» | Соответствует ожидаемому | Тестовый набор состоит из минимальных значений входных данных |
| Анализ граничных условий | Не заполнено ни одно информационное поле нового проекта. | При нажатии «Закрыть проект» перерисовка главной формы | Аварийное завершение программы | Ошибка исправлена |
| Анализ граничных условий | Попытка открыть файл, не являющимся файлом типа .pvr. | В системе при открытии из файла отображаются только файлы типа .pvr. | Подтвердился ожидаемый результат. | Тестовый набор из класса эквивалентности «Недопустимые входные данные» |
| Анализ граничных условий | Открытие проекта из файла, который уже присутствует в системе | Сообщение:”Проект с таким именем уже существует в системе!” | Соответствует ожидаемому | Тестовый набор из класса эквивалентности «Недопустимые входные данные» |
| Анализ граничных условий | Поле “Бюджет” заполнено максимальным количеством “девяток” | Сообщение:”Проект сохранен в ...” | Подтвердился ожидаемый результат. | Тестовый набор состоит из максимальных значений входных данных |
| Анализ граничных условий | Поле “Бюджет” заполнено нулями и в конце числа поставлена цифра | Сообщение:”Проект сохранен в ...” | Подтвердился ожидаемый результат. В бюджет записалась цифра после нулей. | Тестовый набор из класса эквивалентности «Недопустимые входные данные» |
| Анализ граничных условий | Указание “Срок сдачи проекта” на дату в прошлом. | Сохранен без ошибок. Проекту присвоен статус просрочен. | Соответствует ожидаемому | Тестовый набор состоит из минимальных значений входных данных |
| Анализ граничных условий | Добавление артефакта участником из другого проекта затем его удаление и восстановление в проект. Просмотр журнала изменении артефактов участника | Автором артефакта является участник другого проекта | Аварийное завершение программы. Не найден ID. | Исправлено |
| Анализ граничных условий | Создали новый проект в системе, но не сохранили, можно было его удалить. | Проект удален. | Аварийное завершение программы. Удаляемый проект, должен быть в списке проектов системы. | Тестовый набор состоит из минимальных значений входных данных. Ошибка исправлена |
Список обнаруженных и устраненных ошибок:
| Симптомы ошибки | Условия возникновения | Гипотезы | Примечания |
| Файлы проекта сохранялись не в ту директорию | Открытие проекта, который находится не в нижней строчке таблицы главной формы ПС | В список путей сохранялось неверное значение | Переменная, хранящая путь к проекту, с которым идет работа, получала новое значение только при создании нового проекта( последнего в списке). Ее своевременное обновление устранило ошибку. |
| В список участников с таким же именем попадал участник, созданный в текущем проекте | Участник добавлен в текущий и в другой проект | Участник заносится в список из другого проекта | Изначально в список не включались только участники с таким же именем, найденные в данном проекте. Было добавлено сравнение id участников |
| Неверно работал поиск по участникам | При добавлении участника из другого проекта в текущий и последующем его поиске, участник выводился дважды | Проблема с присваиванием идентификаторов участников | Переменная, хранящая максимальный id была объявлена в каждом проекте. Теперь она хранится вне списка |
| Удалялся не тот проект с соответствующей директорией | В списке более одного проекта и пользователь пытался удалить проект не из последней строчки таблицы главной формы. | В процедуре удаления передавался путь к проекту из последней строчки таблицы главной формы. | |
| Запускался поиск по проектам, даже если их нет. | При отсутствии проектов в системе, пользователю был доступен поиск по проектам. | Не было проверки на существование проектов в системе | Устранено добавлением соответствующей проверки. |
| Неправильно отрабатывала функция удаления проекта, если его не сохранили до этого. | Если создали новый проект в системе, но не сохранили, можно было его удалить. | Не было проверки на существование удаляемого проекта в списке проектов системы. | Добавлена соответствующая проверка на существование удаляемого проекта. |
| Разрешалась попытка создания коммуникации в проекте содержащим менее 2 участников | Если в системе есть один участник или нет вообще, пользователю была предоставлена возможность создать коммуникацию | Отсутствовала проверка на количество участников | Исправлено путем добавления проверки количества участников проекта. Их должно быть больше 1 |