|
Содержание работы или список заданий
|
I. Выполнение контрольной работы.
Задание 1. Определить требования к количественным характеристикам качества двух программных продуктов, схожих по назначению (например, двух бухгалтерских программ, двух сайтов и т.д.). В программе MS Excel cоставить таблицу, с помощью которой можно сравнить выбранные программные продукты. Создать диаграмму, позволяющую наглядно представить характеристики качества программных продуктов (гистограмму, диаграмму разброса).
Пример определения требований к количественным характеристикам для двух программных продуктов (А и В) приведен в Таблице 2.
Таблица 2
Количественные характеристики качества программных продуктов А и В
Характеристики качества Содержание требований Мера Программный продукт
А В
Надежность
Завершенность (отсутствие ошибок, наработка на отказ).
Устойчивость к ошибкам.
Восстанавливаемость (перезапускаемость, длительность восстановления). Часы
Часы
Минуты
100
100
0,1
70
90
2
Эффективность
Временная эффективность:
время отклика (получения результатов на типовое задание);
пропускная способность (число типовых заданий, исполняемых в единицу времени).
Ресурсная экономичность (использование ресурсов памяти и производительности вычислительных средств).
Секунды
Число в минуту
Проценты
1
200
45
3
50
100
Задание 2. Определить требования к качественным характеристикам качества двух программных продуктов, схожих по назначению. В табличном процессоре MS Excel cоставить таблицу, с помощью которой можно сравнить выбранные программные продукты. Создать диаграмму, позволяющую наглядно представить характеристики качества программных продуктов.
Задание 3. Разработать программный продукт (сайт, базу данных в MS Access или другой среде и т.д.) в соответствии с требованиями и определить для него требования (предметная область выбирается самостоятельно).
План работы:
1. Описание предметной области.
2. Функциональные требования к программному продукту (показатели качества).
3. Количественные требования к системе (показатели качества).
Методические указания:
Описание предметной области.
Предположим, выбрана предметная область «Справочник по компьютерной технике». В настоящее время в городе работает около 500 фирм по продаже компьютеров и комплектующих к ним. Большую часть ассортимента составляют одинаковые товары, отличающиеся только ценой. Покупатель перед покупкой анализирует прайс-листы фирм-продавцов и выбирает с помощью эксперта либо комплектующие с интересующими характеристиками, либо собранный ПК. Для покупателя рассчитывается цена собранного ПК и рассматриваются альтернативные варианты. На основе анализа принимается решение о том, какие комплектующие или ПК и в каких фирмах приобрести. Покупателя могут заинтересовать технические характеристики определенной модели, отзывы специалистов и другая информация.
Функциональные требования к системе.
1. в системе должна храниться информация о ценах на комплектующие ПК или собранные ПК по нескольким фирмам.
2. предусмотреть возможность обновления каталога товаров и цен на основе общей формы прайс-листов.
3. пользователь должен иметь возможность подбирать комплектующие по интересующим значениям параметров и пределам цены в разных фирмах.
4. при подборе полной конфигурации ПК система должна «запомнить» выбранные пользователем комплектующие и вносить их в комплектацию ПК с учетом их совместимости.
5. должно обеспечиваться хранение нескольких вариантов конфигурации ПК, выбранных пользователем, для последующего анализа.
6. предусмотреть наличие справочной информации о комплектующих ПК, отзывы экспертов, мнения специалистов.
7. предусмотреть удобный дружественный интерфейс пользователя.
Количественные требования
Должна храниться информация не менее, чем о 15 фирмах, в каждой из которых имеется приблизительно от 50 до 150 наименований товаров и цены на них.
II. Интерактивная деятельность (решение кейса)
Кейс: «Война миров: программисты и тестировщики. А как же качество?»
«Вы не можете создавать хорошие программы без хорошей команды, но большинство софтверных команд ведут себя как проблемная семья»
Jim McCarthy
1. Ситуация
Борис работает ведущим IT-менеджером компании по разработке программных продуктов. Вот его рассказ: «Когда-то я был тестировщиком и в те далекие времена порой был крайне недоволен программистами: вечные сомнительные доводы: «Это не баг, это фича» или «Если это и баг, то незначительный, пусть остается!». Да как же остается, если система колом встает!? Потом я стал программистом. И всё изменилось – меня начали жутко бесить бесконечные возвраты на доработку: То им это не нравится, то тут не работает! Да зачем было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает! Не буду править, пусть остается! В общем, классика – вражда программистов и тестировщиков. А потом я стал IT-менеджером. И понял, что вражда эта губительна для общего дела. К счастью, я хорошо помнил себя и программистом и тестировщиком, что и помогло мне осознать истинную суть проблемы и изменить ситуацию».
Процесс
Пять лет назад в компании был очень простой и понятный процесс разработки:
Задачи --> Программирование <--> Тестирование --> Релиз (результат)
Причем: тестировщики узнавали о задачах только в момент передачи их в тестирование, т.е. о начале разработки новой задачи они уведомлений не получали; программисты не дожидались завершения тестирования задач и приступали к новым задачам немедленно. Все считали подобную ситуацию примером идеальной инкапсуляции! У программистов на вход: новые задачи и возвраты из тестирования, на выход: передача задач в тестирование. У тестировщиков: на вход- задачи от программистов, на выход- возврат задач программистам и официальный выпуск версии. Собственно, процесс хорош– каждый живет в своем мире и занимается любимым делом!
Но ведь у этого процесса есть вполне конкретная конечная цель – выпуск качественного ПО с нужным функционалом в срок. В этот момент и начинаются проблемы: приходит менеджер и начинает напоминать о конечной цели.
Типичная ситуация: Менеджер приходит к программистам и спрашивает «когда?», а они отвечают «не знаем, мы все сделали, спросите у тестировщиков».Менеджер идет к тестировщикам с тем же вопросом «когда?», а они ему отвечают: «Разработчики только утром выдали сборку, мы только сейчас приступили к тестированию, и точно будет возврат – тут багов уже много вылезло, поэтому мы не знаем когда будет выпуск – спросите у программистов». И менеджер начинает ходить по кругу туда-сюда, а релиза все нет и нет. В итоге, терпение менеджера кончается, он собирает программистов и тестировщиков вместе и пытается как-то решить вопрос. Собственно, все решения сводятся к выработке правил взаимодействия между программистами и тестировщиками. И все дальнейшие усилия менеджера направлены на контроль за соблюдением этих правил. Вот некоторые правила, которые сформировались в отделе спустя несколько месяцев изнурительной работы менеджера:
• Совместное планирование. Версия планируется заранее. На планировании присутствуют и программисты и тестировщики. Благодаря этому, все заранее знают, что им предстоит делать. Например, это позволяет тестировщикам заранее начать составлять планы тестирования и подготавливать необходимое тестовое окружение.
• Маленькие версии. Это попытка сократить разработку, ведь это накладные расходы на актуализацию кода и повторное тестирование. Если делать маленькие версии, то можно работать сразу в основной ветке.
• Ничегонеделанье. Ещё одна попытка сократить разработку. Когда накапливается много задач, и разработка сильно убегает вперед от тестирования, то программистам разрешается просто ничего не делать, чтобы ещё больше не убегать вперед.
• Раннее информирование. Например, тестировщик приступил к тестированию задачи. Задача большая, но он уже сразу нашел дефект. Он сообщает об этом программисту сразу при обнаружении, а не в конце, когда все тестирование завершено. Или наоборот, программист ещё во время разработки сообщает тестировщику о нюансах реализации, чтобы тот заранее подготовил тест-план. Это позволяет развести работу программиста и тестировщика.
Все эти правила на самом деле хоть и помогли улучшить ситуацию, но кардинально её не изменили. Они как будто затыкали по одной маленькой дырочке. Чувствовалось, что есть какое-то другое решение, что что-то упущено из виду. Например, как только менеджер расслаблялся – почти сразу все договоренности между программистами и тестировщиками забывались, и все возвращалось к исходному состоянию.
Более того, взаимоотношения между программистами и тестировщиками не улучшались – как была вражда, так она и осталась.
Осознание
Борис, как ведущий IT-менеджер, много размышлял о причинах происходящего, о поведении людей, об их эмоциях, потребностях и мотивах. А потом вдруг всё стало ясно! Да ведь сама структура такого подхода, когда «одни программируют – другие тестируют» порождает конфликт между программистами и тестировщиками. И вся суть этого конфликта в том, что у них разные цели! У тестировщиков цель «протестировать». У разработчиков цель «разработать», т.е. «передать в тестирование». А цель «выпустить релиз» только у менеджера. И только пока он прикладывает к этому усилия – она достигается. А когда у людей разные цели – им не по пути, они не интересны друг другу. Как их не притягивай, они все равно будут идти своей дорогой, в разные стороны.
Решение
Собственно, решение проблемы и заключается в том, чтобы поставить и перед программистами и перед тестировщиками одну общую цель. Причем цель очевидную – выпуск качественного программного продукта в срок. Ведь не достигая эту цель, локальные цели «разработать» и «протестировать» теряют всякий смысл. Изменить цели оказалось делом не простым. Но поскольку Борис полностью проникся логикой своих мыслей – то был готов сломить любое сопротивление изменениям! Вот основное, что было сделано:
1. Изменена организационная структура отдела. Вместо отделов разработки и тестирования сформированы команды, в которых собраны и программисты и тестировщики.
2. Переезд подразделений. Вновь сформированные команды получили по отдельной комнате. Теперь не было ситуации, когда тестировщики и программисты сидят в отдельных комнатах и живут своей жизнью.
3. Пропаганда. Пришлось сказать немало пламенных речей о том, для чего и почему затеяли реорганизацию. И главное – донести до всех общую цель.
4. Увольнение. Увы, но кто-то не согласился с новыми идеями. Они уступили дорогу тем, кто теперь приносит куда больше пользы.
И все эти усилия того стоили! Эффект оказался просто поразительным! Напряженные отношения между программистами и тестировщиками исчезли, как будто и не было.
• Появилась взаимная поддержка, продукты стали качественнее.
• Программисты стали помогать тестировщикам, указывая на узкие места, которые стоит дополнительно проверить.
• Изменилось общее отношения к обнаруживаемым дефектам. Никто никого не считает виноватым. Даже наоборот, разработчик благодарен тестировщику, что тот помог сделать продукт лучше.
• Все договоренности о взаимодействии программистов и тестировщиков стали выполняться сами собой – потому что все поняли их эффективность.
• В общем, все заработало как часы – регулярные релизы, качественный продукт.
На глазах за полгода произошло настоящее преображение!
Вывод
У любого конфликта всегда есть истинная причина. У типичного конфликта между программистами и тестировщиками истинная причина – это разные цели. Стоит поставить перед ними одну общую цель – и все сразу изменится! Программисты и тестировщики станут лучшими друзьями, всегда будут помогать друг другу, а от этого выиграют все – и программисты, и тестировщики, и менеджеры, и продукты, и компания!
2. Проблема указанной ситуации состоит в следующем: какие методы управления качеством программного продукта целесообразно применять в данной ситуации? Не забывайте, что эти методы касаются не только программного продукта, но и людей, разрабатывающих его! Прав ли Борис, применив перечисленные методы? Какие из предложенных методов наиболее эффективны?
3. Ключевое задание.
Рассмотреть представленную ситуацию и разработанные мероприятия по устранению проблем в разработке. Проанализировать возможности на предмет реальности проведения всех намеченных (предложенных Вами) мероприятий. Разработать свои варианты решения проблем и обосновать оптимальный вариант.
|