 |
Зависимости между модулями
|
|
|
|
Композиция (как и программирование вообще) - дело непростое. Одни модули используют другие, из-за чего возникают сложные зависимости. И вот уже любую систему нельзя рассматривать как набор модулей, поскольку это монолит, собранный из того, что замышлялось как модули, и обвязанный вокруг зависимостями, при этом ни один модуль не может работать без других. Модифицировать такую систему не просто трудно, а невозможно.
Для борьбы с этим явлением существует несколько методов. Один из них называется Законом Деметры (не имеет прямого отношения к богине плодородия, просто так назывался проект, в котором развилась эта техника), он формулируется так: «Never talk to strangers» - «Никогда не разговаривайте с неизвестными». Проектировать системы таким образом сложно, хотя возможно. К этому правилу следует относиться как к рекомендации.
Гораздо более действенное правило формулируется как «Low coupling, high cohesion» - «Низкая связность, высокое зацепление». Каждый модуль должен быть связным (логически единым) - элементы внутри модуля должны быть сильно связаны между собой, иначе его стоит разделить на несколько модулей. Различные модули должны быть связаны как можно меньше. Идеальным является случай, когда связи между модулями совсем не образуют циклов: B не зависит от A (прямо или косвенно, через другие модули), если A зависит от B.
То же самое можно выразить в терминах горизонтальных и вертикальных зависимостей. Пусть по вертикали идут уровни абстракции, а по горизонтали на каждом уровне - модули, соответствующие этому уровню. Так вот горизонтальных связей должно быть как можно меньше (лучше, чтобы не было совсем), в то время как вертикальные связи (следствие композиции) должны быть четкими.
|
|
|
Выполнение этого правила облегчает композицию и поддерживает систему в виде стройного набора модулей.
Цена качества
В программировании в цене качества выделяют согласованную (conformance) и несогласованную (non-conformance) цену. Согласованная цена включает все планируемые затраты на повышение качества и предупреждение появления несоответствий. Несогласованная цена - это незапланированные потери, связанные с рекламациями, переделками, переносом сроков проекта и т.д.
Статистические исследования на реальных проектах показывают, что несогласованная цена качества уменьшается существенно быстрее, чем увеличивается согласованная цена. Фактически это означает, что затраты на качество, безусловно, выгодны и должны окупаться не только в перспективе через расширение рынка, но и непосредственно в каждом текущем проекте.
Трудность в том, чтобы спланировать и отслеживать затраты на качество в прямой зависимости от получаемых результатов. То есть речь идет об управлении качеством. Одна из основополагающих идей состоит в том, что мы можем управлять качеством разрабатываемого продукта в основном через процесс его изготовления.
Качество продукта возрастает на каждой стадии процесса: во-первых, как прямое следствие зрелости и технологичности самого процесса, и во-вторых, вследствие использования промежуточного продукта, произведенного на предыдущей стадии, более высокого качества. То есть при сложном производстве качество накапливается в продукте кумулятивным образом, причем вклад в качество, сделанный на ранних стадиях, больше влияет на конечный продукт, чем вклад, сделанный на заключительных этапах. Если говорить о цифрах, то прибыль от затрат на качество в бюджетах проектов может составлять от 50 до 200%, при условии их адресности и своевременности.
Система управления качеством
|
|
|
домашний программный сеть
Система управления качеством включает в себя следующие пункты:
· Качество во время разработки - соблюдение правил программирования и тестирования программы. Это снижает себестоимость ПО.
· Качество во время работы программного продукта - безопасность использования, качественная защита информации, время, затрачиваемое на отклик программы, интуитивно-понятный интерфейс, отсутствие перебоев в работе программы.
· Качество во время закупок (документация, контроль) - во время закупок также необходимо контролировать качество ПО, а именно его соответствие документациям.
· Качество оборудования - установка на рабочих местах оборудования, обеспечивающего беспроблемную работу программы (современные компьютеры, ОС и т.д.)
· Качество технической поддержки - оперативное устранение неисправностей в работе ПО, консультация по работе ПО от разработчиков.
· Качество обучения использованию ПО - обучение персонала работе с продуктом в кратчайшие сроки. Инструкция по использованию ПО для клиентов Домашней Сети в свободном доступе.
Окупаемость
Допустим, весь наш программный продукт стоит 1 млн. руб. Окупаемость его будет зависеть первым делом от развития Домашней Сети, количества подключенных домов и абонентов. Если Сеть покрывает хотя бы один район города, и число абонентов равняется 10.000, то окупаемость программного продукта наступит уже через три месяца, с учётом прибыли Сети и вычета зарплат работникам, аренды помещений и т.д.
Заключение
В процессе проведенного исследования была описана система управления качеством разработки ПО, предназначенного для использования в любой Домашней Сети провайдера Internet. Дано понятие Домашней Сети. Обрисованы внешние и внутренние критерии качества, цели и принципы создания ПО. Пути повышения качества ПО, а также окупаемость всего проекта.
Список использованной литературы
1. Огвоздин В.Ю. Управление качеством: Основы теории и практики: Учебное пособие. - 4-е изд., испр. и доп. - М.: Издательство «дело и Сервис», 2002.
2. http://ru.wikipedia.org/
. «Управление качеством в процессах разработки программного обеспечения»
. Виктор Вайнштейн, Михаил Македонский, Александр Попов. Статья с сайте «Компьютерра». http://www.computerra.ru/
. «Базовые концепции. Качество». Андрей Бреслав. http://teormin.ifmo.ru/education/software-design/basic-principles.html
|
|
|
