Разработка системы StudyKit

ВВЕДЕНИЕ 1
Глава 1. ПОСТАНОВКА ЗАДАЧИ 4
1.1. Общая постановка задачи 4
1.2. Данные для решения задачи 5
1.2.1. Назначение и цели 5
1.2.2. Бизнес-процессы 6
1.2.3. Бизнес-роли 6
1.2.4. Бизнес требования 7
1.2.5. Системные требования 8
Глава 2. АКТУАЛЬНОСТЬ ЗАДАЧИ 10
Глава 3. ПЛАНИРОВАНИЕ КАЧЕСТВА 13
3.1. Разработка модели качества 14
3.2. Разработка плана управления качеством 18
Глава 4. ОБЕСПЕЧЕНИЕ КАЧЕСТВА 22
4.1. Разработка плана обеспечения качеством 22
4.2. Аудит качества 24
4.3. Анализ процессов 24
Глава 5. КОНТРОЛЬ КАЧЕСТВА 27
5.1. Планирование работ по тестированию 28
5.1.1. Определение уровней тестирования 29
5.1.2. Определение видов тестирования 31
5.1.3. Определение техник тестирования 31
5.1.4. Определение инструментов тестирования 32
5.1.5. Разработка плана тестирования 33
5.2. Проектирование и выполнение тестов 39
5.3. Тестирование документации 35
5.4. Анализ полученных результатов 40
Глава 6. ТЕХНОЛОГИИ РЕШЕНИЯ 42
ЗАКЛЮЧЕНИЕ 44
ЛИТЕРАТУРА И ИСТОЧНИКИ 45
ЛИСТИНГ 46
Купить

Существует популярное мнение, которое определяет качество как что-то нематериальное и неизмеримое. Как то, о чем бесконечно рассуждают, но так и не могут измерить. Например, известные и часто используемые в повседневной жизни высказывания: «хорошее качество» и «плохое качество» не отражают на самом деле степень качества того или иного предмета. Чаще всего, используя подобные выражения, люди опираются на свое личное мнение и предпочтения, поэтому воспринимают и интерпретируют термин различно. Таким образом, его нельзя определить, как то, что можно проконтролировать, и более того количественно измерить. Но такая точка зрения порождает противоречие по отношению к подходам управления качеством, которые определяют качество как измеримую величину, которая поддается управлению, контролю и изменению.
Другое популярное мнение, определяет качество, как сорт продукта. Под сортом подразумевается категория продукта, имеющего одинаковые функциональные задачи, но разные технические характеристики. Более высокая цена и функциональная сложность продукта все чаще оказывается свидетельством высокого уровня качества, в отличие от более дешевых и простых аналогов. Такое представление о качестве позволяет утверждать, что программное обеспечение, основной задачей которого является редактирование текста, позволяющее редактировать также графические изображения - качественное ПО, в отличие от аналога, не предоставляющего возможность редактирования изображений, вне зависимости от количества сбоев во время работы. Основываясь на таком подходе, качество ограничивается конечным классом продуктов, предоставляющих обилие функциональных и технических характеристик.
Таким образом, продукт с функционалом, позволяющим успешно справляться с поставленной задачей, но ограниченный этой задачей, вероятнее всего не будет классифицирован как качественный.
Такие мнения порождают расплывчатое и неоднозначное представление о качестве, которое не может быть использовано в процессе разработки для повышения качества программного обеспечения. В связи с этим, появляется необходимость в однозначном и точном определении. Такое определение первым предложил Фил Кросби, американский предприниматель, внесший большой вклад в теорию и практику менеджмента, определив качество как «соответствие требованиям». Немного позже, Уотс Хамфри, автор концепции модели оценки зрелости CMM (Capability Maturity Model), описал качество как “достижение определенного уровня пригодности к использованию”. Несмотря на отличие определений, именно вместе они наиболее точно раскрывают термин “качество”.
«Соответствие требованиям» говорит о том, что требования необходимо настолько однозначно определить, чтобы они были понятными и корректно интерпретированы. Прежде всего, это связано с тем, что процесс разработки сопровождается постоянными изменениями разрабатываемого продукта. Каждое несоответствие требованиям рассматривается как дефект. Таким образом, программное обеспечение, которое может позволить пользователю редактировать графические изображения без ошибок, но процесс редактирования текста сопровождается различного рода ошибками, является качественным графическим редактором, но не текстовым.
В свою очередь, текстовый редактор, который не только обеспечивает возможность редактирования текста без ошибок, но и поддерживает все возможные популярные форматы текстовых документов является качественным, с точки зрения пригодности к использованию. Определение качества ПО, как пригодного к использованию, подразумевает удовлетворение требованиям и ожиданиям конечных пользователей. Наиболее популярным ожиданием является удобство использования и возможность удовлетворения пользовательских потребностей. Однако пользователи могут использовать продукт по-разному, следовательно, продукт должен обладать разнообразными вариантами использования.
Каждый такой вариант использования может быть представлен в виде характеристики качества и классифицироваться как параметр пригодности к использованию ПО.
Таким образом оба определения раскрывают термин “качество”, как измеряемую величину. Разница в том, что качество рассмотрено с двух точек зрения: потребителя и производителя. С точки зрения потребителя, заказчика или пользователя продукта, качество — это пригодность к использованию. Степень соответствия возможностей продукта потребностям пользователя. Если продукт предоставляет возможность сделать то, в чем нуждается пользователь, облегчает работу пользователя и может быть использован так, как ему удобно, то данный продукт будет классифицирован как качественный.
С точки зрения производителя и команды разработки, качество — это соответствие специфицированным требованиям. Если реализованный продукт удовлетворяет всем требованиям, поставленным в начале разработки, то продукт также будет классифицирован как качественный.
В таком случае, качественный продукт, с точки зрения производителя, не гарантирует качество, необходимое пользователю. Это связано с тем, что чаще всего собранные требования отражают лишь часть всех реальных требований и ожиданий потребителя. Для решения данной проблемы необходимо определить качество, как соответствие реальным требованиям, явным и неявным. Под неявными требованиями подразумеваются потребности пользователя, которые для него настолько очевидны, что он даже не предполагает, что они могут быть неизвестны разработчикам. На практике, пользователь будет удовлетворен тогда, когда продукт будет полностью удовлетворять его требованиям, как специфицированным, так и нет. [3]

Купить