tehnologia (Г.С. Иванова - Учебник - Технология программирования), страница 8

При этом для наиболее сложных процессовсоздают частичный прототип: разрабатывают экранную форму и диалог. По результатаманализа процессов определяют количество так называемых функциональных точек ипринимают решение о количестве подсистем и, соответственно, команд, участвующих вразработке.38Под функциональной точкой в технологии RAD понимают любой из следующихфункциональных элементов разрабатываемой системы:• входной элемент приложения (входной документ или экранная форма);• выходной элемент приложения (отчет, документ или экранная форма);• запрос (пара «вопрос/ответ»);• логический файл (совокупность записей данных, используемых внутри приложения);• интерфейс приложения (совокупность записей данных, передаваемых другомуприложению или получаемых от него).Нормы, рассчитанные исходя из экспертных оценок, для систем со значительнойповторяемостью кодов определяются следующим образом:• менее 1 тыс. функциональных точек – 1 человек;• от 1 до 4 тыс.

функциональных точек – одна команда разработчиков;• более 4 тыс. функциональных точек – одна команда на каждые 4 тыс. точек.В соответствии с этими нормами разрабатываемую систему делят на подсистемы, слабосвязанные по данным и функциям, и точно определяют интерфейсы между различнымичастями. Использование CASE-средств при этом позволяет избежать неконтролируемогоискажения данных при передаче информации о проекте со стадии на стадию.Далее разработка ведется группами разработчиков, которые продолжают прорабатыватьсвои части системы.

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

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

Оценка качества процессов создания программного обеспеченияКак уже упоминалось выше, текущий период на рынке программного обеспеченияхарактеризуется переходом от штучного ремесленного производства программныхпродуктов к их промышленному созданию. Соответственно возросли требования к качествуразрабатываемого программного обеспечения, что требует совершенствования процессов ихразработки. На настоящий момент существует несколько стандартов, связанных с оценкойкачества этих процессов, которое обеспечивает организация-разработчик. К наиболееизвестным относят:• международные стандарты серии ISO 9000 (ISO 9000 - ISO 9004):• СММ – Capability Maturity Model – модель зрелости (совершенствования) процессовсоздания программного обеспечения, предложенная SEI (Software Engineering Institute –институт программирования при университете Карнеги-Меллон);• рабочая версия международного стандарта ISO 1ЕС 15504: Information Technology –Software Process Assessment: эта версия более известна под названием SPICE – (SoftwareProcess Improvement and Capability dEtermination – определение возможностей и улучшениепроцесса создания программного обеспечения).Серия стандартов ISO 9000.

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

В итоге авторы смогли добиться такой степениподробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков,желающих качественно улучшить существующие процессы разработки, привести их к определеннымстандартам.40СММ определяет пять уровней зрелости организаций-разработчиков, причем каждыйследующий уровень включает в себя все ключевые характеристики предыдущих.1. Начальный уровень (initial level) – описан в стандарте в качестве основы для сравнениясо следующими уровнями. На предприятии такого уровня организации не существуетстабильных условий для создания качественного программного обеспечения.Результат любого проекта целиком и полностью зависит от личных качествменеджера и опыта программистов, причем успех в одном проекте может бытьповторен только в случае назначения тех же менеджеров и программистов наследующий проект.

Более того, если эти менеджеры или программисты уходят спредприятия, то резко снижается качество производимых программных продуктов. Встрессовых ситуациях процесс разработки сводится к написанию кода и егоминимальному тестированию.2. Повторяемый уровень (repeatable level) – на предприятии внедрены технологииуправления проектами. При этом планирование и управление проектамиосновывается на накопленном опыте, существуют стандарты на разрабатываемоепрограммное обеспечение (причем обеспечивается следование этим стандартам) испециальная группа обеспечения качества.

В случае необходимости организацияможет взаимодействовать с субподрядчиками. В критических условиях процесс имееттенденцию скатываться на начальный уровень.3. Определенный уровень (defined level) – характеризуется тем, что стандартный процесссоздания и сопровождения программного обеспечения полностью документирован(включая и разработку ПО, и управление проектами).

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

Управляемый уровень (managed level) – в организации устанавливаютсяколичественные показатели качества как на программные продукты, так и напроцесс в целом. Таким образом, более совершенное управление проектамидостигается за счет уменьшения отклонений различных показателей проекта. Приэтом осмысленные вариации в производительности процесса можно отличить отслучайных вариаций (шума), особенно в хорошо освоенных областях.5. Оптимизирующий уровень (optimizing level) – характеризуется тем, что мероприятияпо улучшению применяются не только к существующим процессам, но и для оценкиэффективности ввода новых технологий.

Основ-41ной задачей всей организации на этом уровне является постоянное улучшениесуществующих процессов. При этом улучшение процессов в идеале должно помогатьпредупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы поуменьшению стоимости разработки программного обеспечения, например с помощьюсоздания и повторного использования компонентов.Сертификационная оценка соответствия всех ключевых областей проводится по 10балльной шкале. Для успешной квалификации данной ключевой области необходимонабрать не менее 6 баллов. Оценка ключевой области осуществляется по следующимпоказателям:• заинтересованность руководства в данной области, например, планируется липрактическое внедрение данной ключевой области, существует ли понимание у руководстванеобходимости данной области и т.д.;• насколько широко данная область применяется в организации, например, оценке в 4балла соответствует фрагментарное применение;• успешность использования данной области на практике, например, оценке в 0 балловсоответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется приналичии систематического и измеримого положительного результата практически во всейорганизации.В принципе, можно сертифицировать только один процесс или подразделениеорганизации, например, подразделение разработки программного обеспечения компанииIBM сертифицировано на пятый уровень.

Кстати, в мире существует совсем немногокомпаний, которые могут похвастаться наличием у них пятого уровня СММ хотя бы в одномиз подразделений – таких всего около 50-ти. С другой стороны, насчитывается несколькотысяч компаний, сертифицированных по третьему или четвертому уровням, т. е. существуетколоссальный разрыв между оптимизированным уровнем зрелости и предыдущимиуровнями.

Однако еще больший разрыв наблюдается между количеством организацийначального уровня и числом их более продвинутых собратьев – по некоторым оценкам,свыше 70 % всех компаний-разработчиков находится на первом уровне СММ [3].SPICE. Стандарт SPICE унаследовал многие черты более ранних стандартов, в томчисле и уже упоминавшихся ISO 9001 и СММ. Больше всего SPICE напоминает СММ.Точно так же, как и в СММ, основной задачей организации является постоянное улучшениепроцесса разработки программного обеспечения. Кроме того, в SPICE тоже используетсясхема с различными уровнями возможностей (в SPICE определено 6 различных уровней), ноэти уровни применяются не только к организации в целом, но и к отдельно взятымпроцессам.В основе стандарта лежит оценка процессов.

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