 |
Формирование процесса разработки ПО
|
|
|
|
Процесс разработки должен быть построен таким образом, чтобы обеспечить возможность измерения качества продукта. В практике программирования наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку (FP).
Однако если под качеством понимать степень удовлетворения требований, то мы должны измерять выполнение требований в конечном продукте. Это достигается организацией процесса разработки, предусматривающего создание на основе требований плана тестирования. Далее на основе плана должны быть разработаны тестовые задания (test cases), затем соответственно тесты и тестовые процедуры. В итоге обеспечивается полное тестирование всех требований и возможность измерения степени выполнения требований в готовящейся версии программы.
Возможная «утечка» качества происходит в рассогласовании всех этих документов в сложных проектах. Обеспечение стабильности процесса возлагается на контроль качества, который должен выявлять несоответствия и информировать о них разработчиков и руководителей проекта.
В полной мере управлять качеством можно, если оно измеряется на всех этапах жизненного цикла. Качество к промежуточному продукту может быть установлено на основе отраслевых стандартов, в данном случае стандартов программирования (например, ISO или IEEE).
Вероятно, одной из самых больших трудностей, связанных с формированием процессов разработки ПО, является обеспечение целостности и согласованности всех действий и требуемых результатов. Особенно это важно для проектов, которые выполняются многочисленной командой разработчиков. Например, обычной ситуацией является изменение требований или проектных решений в процессе разработки; в этом случае должны быть каскадно изменены и приведены в соответствие все связанные, разработанные к этому времени промежуточные продукты и документы.
|
|
|
Беда в том, что это требует высоких трудозатрат, нередко выполняется не полностью и приводит к потере качества продукта. Поэтому важно, чтобы процесс был высоко автоматизирован и поддерживался инструментальными средствам не только в части основных программных процессов, но и в отношении вспомогательных процессов, таких как конфигурационное управление, документирование и т.п. При этом важно использовать интегрируемые между собой инструментальные средства для обеспечения автоматической прослеживаемости связанных промежуточных результатов проекта.
Критерии качества ПО
В фундаментальной работе Бертрана Мейера (создателя языка Eiffel) приводится достаточно подробная классификация критериев (факторов) качества программного обеспечения. Мейер делит эти факторы на «внешние», то есть те, которые может обнаружить пользователь ПО, и «внутренние» - те, которые видят только программисты, создающие это ПО.
Внешние факторы: корректность, устойчивость, расширяемость, повторное использование, совместимость, эффективность, переносимость, простота использования, функциональность, своевременность.
Примеры внутренних факторов: читаемость, модульность, легкость обнаружения ошибок.
Список «внешних» факторов может удивить: почему такие факторы как расширяемость и повторное использование (не видимые конечному пользователю) стоят в одном ряду с простотой использования и корректностью? Дело в том, что термины «ПО» и «пользователь» нужно понимать не только как «прикладные программы» и «оператор ПК», но и как «библиотеки» и «программист, использующий библиотеку».
|
|
|
Действительно, значительная часть создаваемого в мире ПО не является самостоятельными программами, но представляет собой библиотеки и API (к таким продуктам относятся не только библиотеки стандартных классов, такие как STL или Collection Framework, но и, например, ядра операционных систем).
Очень важно понимать, что даже если программист лично работаете над приложением (а не над библиотекой) не в одиночку, а в команде, он все равно создает большое количество API, которыми будут пользоваться его коллеги и он сами. Эти API могут быть не столь жестко регламентированы, как API ядра операционной системы, которое очень опасно менять от версии к версии. Однако чем лучше спроектированы внутренние интерфейсы, тем меньше проблем возникает при их использовании. Кроме того, многие приложения имеют внешние API для расширения (так называемые plug-in API), которые очень близки к API ОС.
Внешние факторы качества
Рассмотрим внешние факторы качества ПО. Здесь применяется термин «программа» - менее точный, чем «ПО», однако более привлекательный с точки зрения русского языка. Следует помнить, что «программа» - это не только приложение, но и библиотека или иные API.
· Корректность. Программа должна делать то, что от нее ждут. Грубо говоря, программа не должна содержать ошибок.
· Устойчивость. Аварийные ситуации, которые могут возникнуть во время работы программы, не должны приводить к плачевным последствиям.
· Расширяемость. «Software must be soft» - ПО должно быть гибким. Программа должна развиваться в соответствии с потребностями пользователей Сети, менеджеров и системных администраторов.
· Повторное использование. Любой компонент системы должен обладать возможностью повторного использования. Это помогает избежать дублирования кода и «размножения ошибок».
· Совместимость. Программа должна корректно работать в окружении других программ.
· Эффективность - это способность программы как можно меньше зависеть от ресурсов оборудования. Программа должна работать за приемлемое время на как можно более широком круге аппаратных конфигураций (имеются в виду различные по производительности конфигурации одной и той же платформы).
|
|
|
· Переносимость. Программа должна легко переноситься между различными аппаратными или программными средами.
· Простота использования. Освоение программы не должно представлять затруднений для пользователей.
· Функциональность. Система не должна уметь больше, чем необходимо, ведь это делает ее громоздкой для пользователя и осложняет разработку. Однако функциональность не должна быть недостаточной - программа должна уметь все, что нужно пользователям.
· Своевременность. Программа должна появляться тогда, когда она нужна. Если она появится с опозданием, в ней, вероятнее всего, уже не будет смысла для пользователей.
Два последних фактора легче всего проиллюстрировать на коммерческих системах, хотя они актуальны не только для них. Так система с недостаточной функциональностью (то есть корректная система со слишком бедной спецификацией) не сможет конкурировать с более развитыми продуктами. А система, созданная слишком поздно, дает фору по времени конкурентам, которые успевают завоевать симпатии пользователей.
Интересно отметить, что избыточная функциональность влияет, в частности, и на своевременность, поскольку разрабатывать большее количество функций дольше и дороже.
|
|
|
