Информационная система для Домашней Сети провайдера Internet. Разработка и анализ с точки зрения управления качеством ИС

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Содержание

1. Введение	3
2. Что такое Домашняя Сеть?	4
3. Принципы построения Домашней Сети	6
4. Классическая схема развития Домашней Сети	7
5. Актуальность	8
6. Цель	9
7. Описание	10
8. Преимущества	12
9. Недостатки	13
10. Формирование процесса разработки ПО	14
11. Критерии качества ПО	16
11.1. Внешние факторы качества ПО	17
11.2. Внутренние факторы качества ПО	19
12. Цена качества	27
13. Система управления качеством	28
14. Окупаемость	29
15. Заключение	30
16. Список используемых терминов	31
17. Список использованной литературы	32

Введение

Итак, что же такое «качество программного обеспечения»? Что рядовой пользователь ждет от программного продукта? Скажем, от тестового редактора? Как минимум, возможность ввести, отредактировать и сохранить текст. А что не ждет? Ошибок, падений, зависаний и т.п. Изо дня в день мы соприкасаемся с различными программными продуктами. Какие из этих продуктов качественные?

У каждого из нас свои критерии качества, но все многообразие наших вкусов, потребностей и предпочтений можно свести к одному знаменателю: программный продукт должен максимально соответствовать нашим ожиданиям и даже предвосхищать их. Итак, под качеством программного продукта будем понимать степень его соответствия потребностям пользователя. Чем выше степень соответствия, тем лучше качество продукта.

По ISO, качество - это полнота свойств и характеристик продукта, процесса или услуги, которые обеспечивают способность удовлетворять заявленным или подразумеваемым потребностям. Современные способы обеспечения качества базируются на подходах TQM (Total Quality Management). Это управление ресурсами и применение количественных методов анализа для улучшения материалов и услуг, поставляемых в организацию, всех процессов внутри организации, а также степени удовлетворенности настоящих и будущих потребностей клиентов.

Что такое Домашняя Сеть?

Сеть Internet становится все более популярной, однако настоящая популярность придет, когда к ней будет подключен каждый дом. Сейчас же наиболее массовым способом подключения является телефонное соединение - коммутируемый доступ. Скорость его не превышает 56 кбит/c (и то только на приём информации), и поэтому пользоваться мультимедийными ресурсами Internet практически невозможно - IP - телефонии, видеоконференциям, потоковому видео и другим аналогичным сервисам для нормальной работы требуются более высокие скорости.

Сегодня появляются технологии, способные увеличить скорость подключения, но пока они дороги для индивидуального пользователя. Один из возможных вариантов - коллективное подключение к Internet - Домашние Сети.

Домашняя Сеть - это очень удобный для пользователя, способ подключения к Интернет. К квартире пользователя подводится отдельный кабель, который объединяет его компьютер с компьютерами других жильцов дома, района, города. В результате такого объединения получается локальная компьютерная сеть с множеством достоинств. Теперь все компьютеры сети могут общаться друг с другом (игры, обмен различной информацией). Более того, теперь, когда локальная сеть подключена к глобальной сети Интернет, пользователь может вкусить все прелести общения с миром.

Для домашних сетей характерен очень приятный момент - для доступа в Интернет им не нужен модем и соответственно телефон у них не занят, а в случае повременной оплаты за телефон они еще и экономят на деньгах.

Хотелось бы еще сказать, что такой способ подключения к Интернет гораздо более удобен, проще и дешевле, а учитывая более высокую скорость и надежность соединения он еще и приятнее. Это и называется Домашняя компьютерная сеть, т.е. подключение отдельных жилых домов к Интернет с помощью выделенной линии. Это позволяет каждому жильцу, имеющему дома компьютер, пользоваться ресурсами Интернет 24 часа в сутки, достаточно только включить компьютер.

Пользователи смогут запускать внутри домашней сети любые приложения. Опыт эксплуатации домашних сетей показывает, что пользователи активно обмениваются данными внутри квартала, сетевые игры и сеансы Net Meeting, IPX-приложения, необходимые для организации доступа к другим компьютерам сети, мультимедийные сервисы, такие как video-по запросу.

Принципы построения Домашней Сети

Построение домашней сети - это фактически решение проблемы «последней мили», то есть создание дешевых, удобных и наиболее скоростных каналов в Internet для конечных пользователей. Разделим территорию, на которой происходит подключение домашнего компьютера, на три участка.

«Последняя миля 1? - это участок сети между провайдером Internet и домом пользователя. На этом отрезке необходимы высокоскоростные технологии «точка-точка», с помощью которых передается весь поток информации, генерируемый и поглощаемый всеми пользователями, живущими в этом доме. Для последней мили обычно применяют выделенные линии, кабельные модемы, радио-Ethernet, обычный Ethernet и различные оптоволоконные технологии передачи данных.

«Последняя миля 2? - это собственно разводка сигнала внутри дома - раздача Internet по квартирам. Подключать к Internet нужно каждого пользователя в отдельности, то есть для каждого тянуть или искать отдельный кабель к провайдеру. Мы будем называть такое подключение прямым. При коллективном подключении дома требуется технология распределения ресурса по всем участникам проекта. Для этого можно использовать Ethernet.

«Последняя миля 3? - это разводка сигнала по квартире. Конечно, если в квартире проложена СКС, то проблем с подключением компьютера не будет, но в любом другом случае прокладка кабеля по квартире связана с определенными проблемами. Впрочем, даже без подключения к Internet иногда возникает необходимость собрать в единую сеть несколько компьютеров. Для этого можно использовать либо радиотехнологии - Bluetooth или Home FR, либо Ethernet.

Очень много Домашних Сетей строят энтузиасты, которые находят единомышленников в своем доме. Они прокладывают кабель и подключают сеть к Internet. Как правило, такие инициаторы сами же являются и владельцами домашней сети. В этом случае, инициативная группа несет необходимые расходы по замене оборудования, модернизации кабельной инфраструктуры и решению возникающих проблем.

Классическая схема развития Домашней Сети

В квартале выбирается точка присутствия, через которую можно подключить несколько домов. В эту точку ставится маршрутизатор и прокладывается отдельная магистраль - оптоволоконный кабель, могут использоваться кабельные модемы на существующих сетях КТВ, обычный Ethernet, в удаленных районах Radio-Ethernet, либо арендуется выделенная линия, которая обеспечивает подключение домашних сетей к магистрали. При этом маршрутизация потоков выполняется в точке присутствия, а вся разводка по дому осуществляется на коммутаторах. В этом случае, чем дешевле устройства «последней мили 2?, тем проще их защитить от вандализма и заменить при какой-либо аварии. В результате получается одна большая локальная сеть.

В качестве разводки по дому сейчас обычно используют технологию Ethernet. Она привычна, достаточно дешева и ее поддерживают практически все производители.

Разводка по дому с помощью Ethernet обычно делается следующим образом: в каждом подъезде ставят коммутатор, и от него прокладывают кабель «витая пара» до квартиры, кабель оконечивают разъемами или розеткой и вставляют в сетевую карту компьютера.

Актуальность

Любая Домашняя Сеть нуждается в качественном программном продукте, который будет удовлетворять её современным требованиям, таким как: упрощение работы директоров, менеджеров и администраторов Домашней Сети, и обеспечение им тесного контакта с пользователями для своевременного и быстрого решения их проблем.

Стоить помнить, что Домашняя Сеть - это огромный слаженно работающий механизм, требующий наличие качественного ПО для своего бесперебойного функционирования. Понятно, что с ростом количества Домашних Сетей и объёма выполняемых ими работ, растёт и количество требований к ПО, что в свою очередь требует от него постоянного увеличения выполняемых им функций и улучшения их качества.

Цель

В состав программного продукта входит мощный набор средств оптимизации домашних сетей. Пакет программного обеспечения для управления Домашними Сетями, должен дает возможность пользователю настраивать свою сеть, а также управлять ею, не прибегая к помощи специалистов. А менеджерам и администраторам - обеспечивать доступ к уже имеющейся информации и добавлять новую. Этот программный продукт обеспечивает пользователю и работникам Домашней Сети следующие возможности:

· управление, мониторинг и контроль за подключением компьютеров к Интернету,

· диагностика и ликвидация проблем с подключением и производительностью,

· оптимизация производительности и надежности,

· отслеживание истории сети и использования ее ресурсов с помощью отчетности,

· управление активными соединениями и получение данных об их текущем состоянии,

· управление пользовательским доступом и защита сети от несанкционированного доступа.

Программный продукт существенно упрощает работу домашних сетей, избавляя пользователей от необходимости разбираться в тонкостях технологии. Кроме того, это ПО обеспечивает пользователей средствами мониторинга, позволяющими, например, родителям больше не беспокоиться о том, чем их дети занимаются в Интернете.

Продукт имеет удобный пользовательский интерфейс и расширенный набор интерактивных шаблонов, облегчающих и ускоряющих взаимодействие с сетью для обычных пользователей. Новая версия повышает уровень безопасности за счет модернизации функций Network Health (здоровье сети) и Security Alerts (сигналы тревоги). Кроме того, защищенность сети увеличивают новые функции шифрования, а также новые средства контроля над компьютерами, подключенными к сети.

Программное обеспечение включает функции мониторинга, которые позволяют легко и точно проконтролировать, как используется Интернет всеми участниками Домашней Сети. С помощью простого интерфейса администраторы могут по просьбе клиента установить для своих детей ограничения на доступ к отдельным сайтам, играм и Интернету в целом.

Описание

Создаваемый программный позволяет выполнять следующие действия:

Для менеджеров:

· подавать информацию о вновь подключенных клиентах,

· осуществлять доступ к базе клиентов, подавших заявку на подключение, для последующей передачи этой информации работникам ремонтной бригады,

· осуществлять доступ к базе уже имеющихся пользователей,

· осуществлять доступ к базе данных доступных для подключения домов и телефонов потенциальных клиентов,

· добавлять в базу данных клиентов вновь подключившихся, для последующей передачи информации в отдел технической поддержки,

· получать информацию о последних поступивших средствах на счёт клиентов с данными о том, когда и где была произведена оплата и на какую сумму,

· хранить все данные о клиентах, в том числе их контактную информацию, включая адрес и телефон, данные о дате подключения, выбранном тарифе, произведённых пополнениях счёта.

Для работников технической поддержки:

· осуществлять доступ к базе данных всех подключенных клиентов,

· хранить все данные об использующихся IP-адресах, адресах DNS-серверов и т.д.,

· хранить и обеспечивать доступ к данным о заявках клиентов в техническую поддержку для последующего решения их проблем,

· хранить и обеспечивать доступ к данным о дате, времени перебоях в работе сети,

· следить в онлайн-режиме за безопасностью компьютеров, включенных в сеть,

· следить за тем, как используются ресурсы Интернет всеми участниками сети.

Для клиентов:

· обеспечивать доступ к личной информации о выбранном тарифе, текущембалансе, сроках следующего отключения при неуплате и т.д.,

· обеспечивать возможность оставить заявку на изменение тарифа, находясь в личном кабинете,

· получать информацию о предстоящих перебоях в работе сети,

· получать информацию о расходах собственного трафика,

· предоставлять информацию о точках приёма платежей,

· позволять пользователю изменить пароль для входа в личный кабинет,

· предоставлять информацию об истории платежей.

Преимущества ПО

· хранение, получение, изменение информации о всех абонентах Домашней Сети,

· лёгкость получения необходимой информации как для менеджеров и администраторов, так и для клиентов,

· оперативность в получении и обработке заявок о проблемах от пользователей,

· контроль использования клиентами ресурсов Интернет,

· своевременное обнаружение неисправностей в работе Домашней Сети,

· наглядность для клиента о его тарифе, балансе и т.п.

Недостатки ПО

· возможные перебои в работе программного продукта,

· необходимость внедрения продукта в уже имеющуюся систему,

· необходимость обучения пользователей работе с программным продуктом.

Формирование процесса разработки ПО

Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP).

Однако если под качеством понимать степень удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование всех требований и возможность измерения степени выполнения требований в готовящейся версии программы.

Возможная «утечка» качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.

В полной мере управлять качеством можно, если оно измеряется на всех этапах жизненного цикла. Качество к промежуточному продукту может быть установлено на основе отраслевых стандартов, в данном случае стандартов программирования (например, ISO или IEEE).

Вероятно, одной из самых больших трудностей, связанных с формированием процессов разработки ПО, является обеспечение целостности и согласованности всех действий и требуемых результатов. Особенно это важно для проектов, которые выполняются многочисленной командой разработчиков. Например, обычной ситуацией является изменение требований или проектных решений в процессе разработки; в этом случае должны быть каскадно изменены и приведены в соответствие все связанные, разработанные к этому времени промежуточные продукты и документы.

Беда в том, что это требует высоких трудозатрат, нередко выполняется не полностью и приводит к потере качества продукта. Поэтому важно, чтобы процесс был высоко автоматизирован и поддерживался инструментальными средствам не только в части основных программных процессов, но и в отношении вспомогательных процессов, таких как конфигурационное управление, документирование и т.п. При этом важно использовать интегрируемые между собой инструментальные средства для обеспечения автоматической прослеживаемости связанных промежуточных результатов проекта.

Критерии качества ПО

В фундаментальной работе Бертрана Мейера (создателя языка Eiffel) приводится достаточно подробная классификация критериев (факторов) качества программного обеспечения. Мейер делит эти факторы на «внешние», то есть те, которые может обнаружить пользователь ПО, и «внутренние» - те, которые видят только программисты, создающие это ПО.

Внешние факторы: корректность, устойчивость, расширяемость, повторное использование, совместимость, эффективность, переносимость, простота использования, функциональность, своевременность.

Примеры внутренних факторов: читаемость, модульность, легкость обнаружения ошибок.

Список «внешних» факторов может удивить: почему такие факторы как расширяемость и повторное использование (не видимые конечному пользователю) стоят в одном ряду с простотой использования и корректностью? Дело в том, что термины «ПО» и «пользователь» нужно понимать не только как «прикладные программы» и «оператор ПК», но и как «библиотеки» и «программист, использующий библиотеку».

Действительно, значительная часть создаваемого в мире ПО не является самостоятельными программами, но представляет собой библиотеки и API (к таким продуктам относятся не только библиотеки стандартных классов, такие как STL или Collection Framework, но и, например, ядра операционных систем).

Очень важно понимать, что даже если программист лично работаете над приложением (а не над библиотекой) не в одиночку, а в команде, он все равно создает большое количество API, которыми будут пользоваться его коллеги и он сами. Эти API могут быть не столь жестко регламентированы, как API ядра операционной системы, которое очень опасно менять от версии к версии. Однако чем лучше спроектированы внутренние интерфейсы, тем меньше проблем возникает при их использовании. Кроме того, многие приложения имеют внешние API для расширения (так называемые plug-in API), которые очень близки к API ОС.

Внешние факторы качества

Рассмотрим внешние факторы качества ПО. Здесь применяется термин «программа» - менее точный, чем «ПО», однако более привлекательный с точки зрения русского языка. Следует помнить, что «программа» - это не только приложение, но и библиотека или иные API.

· Корректность. Программа должна делать то, что от нее ждут. Грубо говоря, программа не должна содержать ошибок.

· Устойчивость. Аварийные ситуации, которые могут возникнуть во время работы программы, не должны приводить к плачевным последствиям.

· Расширяемость. «Software must be soft» - ПО должно быть гибким. Программа должна развиваться в соответствии с потребностями пользователей Сети, менеджеров и системных администраторов.

· Повторное использование. Любой компонент системы должен обладать возможностью повторного использования. Это помогает избежать дублирования кода и «размножения ошибок».

· Совместимость. Программа должна корректно работать в окружении других программ.

· Эффективность - это способность программы как можно меньше зависеть от ресурсов оборудования. Программа должна работать за приемлемое время на как можно более широком круге аппаратных конфигураций (имеются в виду различные по производительности конфигурации одной и той же платформы).

· Переносимость. Программа должна легко переноситься между различными аппаратными или программными средами.

· Простота использования. Освоение программы не должно представлять затруднений для пользователей.

· Функциональность. Система не должна уметь больше, чем необходимо, ведь это делает ее громоздкой для пользователя и осложняет разработку. Однако функциональность не должна быть недостаточной - программа должна уметь все, что нужно пользователям.

· Своевременность. Программа должна появляться тогда, когда она нужна. Если она появится с опозданием, в ней, вероятнее всего, уже не будет смысла для пользователей.

Два последних фактора легче всего проиллюстрировать на коммерческих системах, хотя они актуальны не только для них. Так система с недостаточной функциональностью (то есть корректная система со слишком бедной спецификацией) не сможет конкурировать с более развитыми продуктами. А система, созданная слишком поздно, дает фору по времени конкурентам, которые успевают завоевать симпатии пользователей.

Интересно отметить, что избыточная функциональность влияет, в частности, и на своевременность, поскольку разрабатывать большее количество функций дольше и дороже.

Внутренние факторы качества

Описанные выше внешние факторы качества программного продукта - это конечная цель, которой необходимо достичь, чтобы разработку можно было считать успешной. Таким образом, задача поставлена.

Итак, достичь хороших показателей внешних факторов качества чрезвычайно трудно. Однако считается, что есть способ облегчить эту задачу: поддерживать на высоком уровне внутренние факторы качества, которых конечный пользователь не видит, зато их видят программисты, создающие систему, и этим программистам легче работать, то есть легче стремиться к достижению внешнего качества системы.

Формулируя грубо, можно определить дизайн как совокупность свойств системы, определяющих ее внутреннее качество. Внутреннее качество порождает внешнее.

Единство дизайна

Первый принцип, обеспечивающее внутреннее качество, формулируется как единство дизайна. Применение разнородных практик в процессе создания системы приводит к тому, что никто не сможет в точности сказать, как это сделано, а главное, как это должно быть сделано.

Как его ни определяй, понятие «хорошего дизайна» относительно, но много разных «хороших дизайнов» в одной программе - это один большой плохой дизайн.

Качество кода

Внутреннее качество начинается с качества исходного кода программы. Основным фактором качества исходного кода программы является его читаемость и понятность.

Код должен быть читаем любым членом команды с любой целью:

· посмотреть, каким же образом программисту удалось написать так плохо работающую функцию,

· выяснить, почему снаружи все так криво выглядит,

· понять, реализовал ли один программист то, что может пригодиться другому.

Необходимо поддерживать читаемость кода на должном уровне. И здесь первым бросается в глаза форматирование. Правила форматирования кода должны быть едиными во всем проекте. Весь новый код необходимо писать в соответствии с принятыми стандартами кодирования для. Многие среды разработки могут автоматически форматировать код. Это может помочь при включении чужого или старого кода в проект, но новый код необходимо создавать сразу правильно.

Не все требования стандарта кодирования очевидны. Например, стандарт регламентирует обязательное использование фигурных скобок при оформлении структурных операторов, даже если тело оператора состоит из одной строки. Это необходимо для повышения читабельности.

Документация

Для того, чтобы код был более понятен, стоит стремиться приблизить его к естественному языку. Поскольку ключевые слова, как правило, пишутся по-английски, лучше всего приближаться к английскому языку.

Так или иначе, хороший код обычно понятен сам по себе, без добавления комментариев. Правильное (осмысленное) именование классов, полей, методов и переменных дает возможность понимать текст программы без дополнительных объяснений. Кроме того, разбиение на методы позволяет выделять фрагменты кода, реализующие определенные функции, и имя метода само по себе является комментарием к такому фрагменту кода.

Однако вчитываться в код метода обычно труднее, чем читать описание, поэтому классы, которыми должны пользоваться другие (а лучше - вообще все классы) должны быть документированы.

Документация (не проектная, а документация кода) должна содержать контракты всех элементов системы (классов, методов, полей), то есть описание тех условий, при которых эти элементы будут работать правильно.

Метафоры

При правильном применении ООП само по себе является шагом вперед на пути к легкому пониманию устройства (дизайна и архитектуры) системы. Как уже было сказано, осмысленные имена классов и методов могут сильно помочь человеку разобраться в коде, поскольку понятия, которыми оперирует система (ее объекты и действия), присутствуют в коде. Таким образом, если человек знает, что делает программа, то ему будет относительно легко понять, как она это делает, потому что он сможет ориентироваться в коде по названиям, совпадающим с понятиями, присутствующими в интерфейсе программы (и / или в предметной области).

Однако часто бывает так, что использовать в коде полные названия трудно - они бывают, например, слишком длинными или вообще не оформляются иначе, чем в распространенном предложении.

Во время разработки (особенно на ее начальных фазах) люди быстро устают употреблять в разговоре длинные термины и придумывают им заменители, возможно, из другой предметной области. Для сложно описываемых понятий имеет смысл выработать метафоры, то есть короткие названия, выражающие суть понятия (возможно, с помощью аналогии).

Метафоры полезны как при описании предметной области, так и при описании деталей реализации. Например, название «всплывающий» для элемента, перемещаемого к концу набора при пузырьковой сортировке, удачно описывает смысл алгоритма.

Растущие сложные системы

Многие факторы внутреннего качества связаны с теми сложностями, которые возникают при развитии программной системы. Лишь небольшое количество программ создается однажды, передается заказчику и никогда более не модифицируется. Большая часть программных систем развивается на фоне изменяющихся требований, условий эксплуатации и круга задач, решаемых системой.

Из довольно небольшой программы может развиться весьма крупный проект.

Это создает много проблем, поскольку изначально нельзя предугадать всех превратностей, ожидающих систему на жизненном пути, как и всех ошибок, совершаемых при ее создании.

Большую систему весьма трудно развивать и поддерживать хотя бы потому, что одному человеку не удержать в голове всех ее особенностей. Поэтому необходимо следовать определенным правилам (как «в большом», так и «в малом»), чтобы в дальнейшем система была достаточно гибкой.

Такой внешний фактор качества ПО, как функциональность, трудно определить однозначно. Здесь в силу вступает так называемый закон 80/20: «80% пользователей используют только 20% функций системы». Почему бы не оставить только 20% и не выкинуть остальные 80%? Дело в том, что для каждого пользователя эти 20% могут состоять из разной функциональности.

Эта проблема касается в основном коробочных продуктов, создаваемых не для конкретного заказчика, а для широкого круга пользователей.

Так или иначе, большинство программ представляют собой неуклонно растущие сложные системы, которые нужно расширять, развивать и выпускать вовремя, и в этом в значительной степени помогает хороший дизайн.

Метрики

Что же все-таки такое «хороший дизайн»? Формально говоря, это такой дизайн, который с гарантией обеспечивает достижение хорошего внешнего качества системы. Но есть одна проблема: скорее всего, единого хорошего дизайна нет.

Никто до сих пор не предложил свода правил, который бы гарантировал внешнее качество. Есть лишь некоторые идеи. Причем речь идет не только о дизайне, но и об архитектуре и об организации разработки всего жизненного цикла ПО.

На практике необходимо хотя бы отличать плохой дизайн. Для этих целей существуют многочисленные метрики: количественные характеристики систем, якобы отражающие их внутреннее качество. Вот некоторые примеры метрик:

· Средняя (или максимальная) длина метода в строках. Надо стремиться к уменьшению этой величины.

· Количество доступных клиентам элементов класса. Тоже стоит уменьшать, поскольку с чересчур большим API трудно работать.

Предложено довольно много метрик. Некоторые из них действительно полезны как рядовым разработчикам, так и людям, управляющим разработкой.

Существует ряд критериев внутреннего качества, которые не выражаются количественно. Это скорее принципы, чем метрики. И от них, как правило, больше толку.

Модульность

Для того чтобы с большой системой можно было работать, ее придется разбить на части. Это нужно и тем, кто пытается понять, как она работает (им хорошо бы сосредоточиться на одной такой части, забыв об остальных). И, конечно, без этого не обойтись тем, кто создает систему: они не смогут ни придумать одно большое решение для огромной проблемы, ни воплотить его, если все вместе будут работать со всей системой разом.

Даже средняя программа не помещается целиком в голове у одного человека, поэтому необходимо разбивать программы на небольшие части. Будем называть такие части модулями.

Разбиение большой задачи на более мелкие называется декомпозицией задачи. Разумно делить систему на модули так, чтобы каждый модуль решал некоторую относительно изолированную задачу, описание которой можно удержать в голове.

На самом деле понятие модуля на разных уровнях абстракции нужно трактовать по-разному. Дело в том, что очень большую задачу стоит разбить на задачи поменьше, эти в свою очередь - на еще более мелкие, и так далее, пока размер задачи не станет подвластен одному человеку.

Каждое разбиение соответствует понижению уровня абстракции, поскольку при таком «измельчении» задачи все более и более конкретизируются (термин «конкретный» - антоним термина «абстрактный»). На каждом уровне задаче сопоставляется некий модуль. Сначала это подсистемы, затем, возможно, пакеты, подпакеты, и наконец, классы. В любом случае каждый модуль должен решать свою задачу и только ее.

Затем из реализаций маленьких задач необходимо составить решение исходной задачи. Этот процесс называется композицией. Композиция - это фактически подъем по уровням абстракции (сборка более крупных модулей из более мелких).

Можно подумать, что процессы декомпозиции и композиции проходят отдельно и разнесены во времени. Как правило, это не так. Все задачи решаются постепенно: выделяются подзадачи, они решаются, интегрируются в систему, выделяются новые подзадачи…

Повторное использование

В процессе выделения небольших задач часто выясняется, что некоторые из них уже были решены: самим программистом, другим производителем ПО (поставщиком библиотеки) или разработчиками стандартной библиотеки языка. Иногда (особенно это касается кода, написанного вашей командой) решение нужно слегка видоизменить (обобщить), чтобы его можно было использовать повторно.

Повторное использование экономит время на решении тех же задач, на понимании стандартных решений, на поиске и исправлении ошибок. Даже если в повторно используемом коде нашлась ошибка, ее потребуется исправить только один раз - и все ее проявления исчезнут.

Для ряда систем повторное использование может являться критерием внешнего качества. Обычно это фактор внутренний. Необходимо проектировать систему так, чтобы все ее компоненты могли быть легко использованы повторно.

Одно из самых страшных зол - дублирование кода. И не только кода: дублирование идей, проектных решений, понятий - все это вредит общему делу.

ООП очень помогает при повторном использовании кода: наследование и полиморфизм - это очень эффективные инструменты для решения таких задач.

Инкапсуляция

Человек склонен быть невнимательным к предупреждениям, написанным в комментариях: он просто их не видит. Если же предупреждения нет, можно считать, что ошибка уже совершена. Самое интересное в том, что автор того или иного класса часто сам норовит его неправильно использовать.

Итак, все модули должны вести себя так, чтобы свести к минимуму возможность совершения ошибки клиентами. Это касается как пользовательского интерфейса, так и API.

Есть идея: чем меньше API, тем проще его защитить. Давайте спрячем от посторонних глаз все, что можно спрятать. Жаль, но спрятать все не получится: надо дать возможность пользоваться модулем. Отсюда следует важный принцип: «Все, что не является необходимым для пользователя, должно быть скрыто».

Все то, что пользователю необходимо, должно работать так, чтобы он не смог допустить ошибки. Причем, лучше всего защищаться даже от таких ошибок, которые еще не известны.

Принцип сокрытия всех деталей реализации называется инкапсуляцией. Его можно сформулировать и так: «Мой модуль делает это. Вам не нужно знать, как».

Ярким примером является правило сокрытия полей в классах. В них не должно быть полей в открытом доступе. Доступ к полям должны обеспечивать специальные методы (accessors). Даже если поначалу эти методы будут работать тривиально, у программиста будет возможность добавить в них более сложное поведение, не сломав клиентский код. Также можно сделать поле доступным только для чтения, и все это поймут: нет метода на запись - значит, нет. Это еще одна иллюстрация необходимости единства дизайна: если во всей системе доступ к полям предоставляется через методы, все будут думать в этих терминах и не будут пытаться искать способ записывать значение в поле, для которого нет метода записи.

Кроме того, инкапсуляция улучшает качество абстракции: оставляя только необходимое, сближается представление об объекте с его интерфейсом. К тому же, скрытую от чужих глаз реализацию можно заменить более эффективной, не нарушив работоспособности клиентов.

Зависимости между модулями

Композиция (как и программирование вообще) - дело непростое. Одни модули используют другие, из-за чего возникают сложные зависимости. И вот уже любую систему нельзя рассматривать как набор модулей, поскольку это монолит, собранный из того, что замышлялось как модули, и обвязанный вокруг зависимостями, при этом ни один модуль не может работать без других. Модифицировать такую систему не просто трудно, а невозможно.

Для борьбы с этим явлением существует несколько методов. Один из них называется Законом Деметры (не имеет прямого отношения к богине плодородия, просто так назывался проект, в котором развилась эта техника), он формулируется так: «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/

3. «Управление качеством в процессах разработки программного обеспечения»

4. Виктор Вайнштейн, Михаил Македонский, Александр Попов. Статья с сайте «Компьютерра». http://www.computerra.ru/

5. «Базовые концепции. Качество». Андрей Бреслав. http://teormin.ifmo.ru/education/software-design/basic-principles.html

Размещено на Allbest.ru