И. Соммервилл - Инженерия программного обеспечения (1133538), страница 135
Текст из файла (страница 135)
Совершенствование производства само по себе ведет к повышению качества готовой продукции. Другое дело — неосязаемые и зависящие от интеллектуалы<ой деятельно. сти процессы производства ПО, которые к тому же не подлежат автоматизации. Ведь качество программного продукта зависит не только непосредственно от производственного процесса, но и от процесса проектирования, в котором главную роль играет человеческий фактор. Хотя лля некоторых видов ПО ключевым в отношении качества является технологический процесс.
однако при реализации новых задач люди, вовлеченные в процесс разработки, остаются ключевым фактором. Существует четыре фактора, принципиальных для качества любой продукции, связанной так или иначе с интеллектуальной деятельностью, будь то программное обеспечение или же книги, фильмы и другие продукты, основой которых является проектирование. Эти факторы представлены на рис.
25.2. Этн факторы могут оказывать различное воздействие, которое зависит от размера и вида программного проекта. Для очень больших систем, состоящих из отдельных подсистем и разрабатываемых разными командами программистов, технология разработки является ю<ючевым фактором, влияющим на качество конечного продукта. Для таких про. ектов проблемными оказываются вопросы интеграции, управления и обеспечения взаимодействия.
Так как разработка ПО продолжается несколько лет, состав рабочих групп 25. Совершенствование производства ПО 517 может лтсняться, кроме того, они состоят из специалистов с самыми разными возможно. стями и опытом. Состав группы может полностью поменяться за период выполнения про. екта. Из этого следует, что влияние талантливых специалистов, имеющих особые навыки. не являетгзгдоминирующим. Тввожхтв разрвбвпв ПО Качество тевкв вкчяскогв врзцэсса Качястяо аьнюлнэния рабвтм людная Свбеспммосгь, время я график работ Рис. 25.2. Освоение фокпго)гьь оеклппбое ка качество прог)газок лого обеспечен ия Однако, если говорить о небольших проектах, где над реализацией работает несколько профессионалов.
качество работы членов команды более важно, чем качественный технологический процесс. Если все члены команды имеют высокую квалификацию и достаточно опытны, более вероятно получение высококачественного продукта. В том случае, если команда не имеет навыков и опыта, качество технологического процесса может способствовать повытпению качества продукции, однако не устранит в полной мере все по. грешности и недоработки. С другой стороны, в небольших командах хорошо разработанная технология имеет особое значение. Ведь члены команды пе могут посвятить все свое время кропотливой бу. мажиой работе.
Наоборот, они проводят основную часть времени за разработкой и программированием системы, поэтому хорошие средства поддержки окаж)тся удачным подспорьем и повысят производительность труда. В больших проектах базовый уровень технологического процесса важен лля управления потоком информации. Парадоксально, но при этом сннжастсл влияние средств поддержки высокого уровня. Члены команды, стараясь понять различные компоненты системы, больше времени тратят на общение, чем па сам процесс програмлтирования. Именно это, а не средства разработки, оказываетсл до. минируютцим фактором, влияющим на нх производительность.
Факторы, положенные в основу прямоугольника на рис. 25.2, наиболее критичны. Качество продукта пострадает в любом случае, как только будет неправильно произведен расчет средств на выполнение проекта (независимо от его размера) либо будет представлен нереальный график работ, что сделает невозможным своевременное вьгполнение проекта.
Для успешной реализации проекта необходимо достаточтюе количество материальных и временных ресурсов. В противном случае прослт может спасти только высококвалифицированный и преданный персонал. И даже тогда при остром дефиците средств может пострадать качество конечного продукта. Довольно часто оказывается, что причина появления на рынке программных прсдук. тов низкого качества кроется отнюдь не в слабом управлении, плохо налаженном произ водстве илн необученном персонале. Причина в другом: компании борются за выживание. Чтобы заполучить контракт на разработку программного продукта, многие компании дают заниженную оценку затрат. Назначение заниженной "выигрышной" цены (см.
главу 23) — это необратимое следствие системы конкуренции. Поэтому неудивительно, что контроль качества товаров в таких условиях оказывается нелегкой задачей. 518 хХасть У1. Унранление 25.2. Анализ и моделирование производства Лиалнз и моделирование производства ПО предполагает изучение используемых процессов разработки и их чодслироваиие для определения ключевых параметров. Описание основных моделей процесса создания ПО представлено в главе 1.
Частныс варианты этих моделей постоянно используются в качестве примеров прн рассмотрении отдельных тем, таких, как разработка требований, проектирование и т.д.. В книге [1бб] можно найти весьма удачный обзор темы моделирования процессов разработки ПО. Лнализ действующей технологии основан на ее тщательном изучении в целях выявления взаимосвязей межлу различными стадиямн процесса производства. Первым шагом будет, несомненно, анализ качества, цель которого — определение основных параметров модели производства. Далее исследователь должен перейти к количественному анализу процесса разработки с пспользоваписл~ различных показателей, значения которых определяются автоматически или вручную. Только после этого технологический процесс можно представить в впдс модели.
Лпалнз технологического процесса можно начать, принимая за основу его стандартную модель, которая существует в большинстве компаний или может опрелеляться заказчиком. В таких стандартных моделях почти всегда определены основные этапы разработки и жизненный цикл создаваемых программных продуктов. Стандартные модели удобны для начала анализа процесса создания ПО.
Однако такие модели слишком обобщенные и прелпазпачены лишь для общего описания основных этапов процесса разработки программного обеспечения. Всегда важно проникнуть в суть модели н выявить реально действующий процесс. Кроме того, действующий процесс может значительно отличаться от формальной модели.
В анализе производственного процесса используется два метода. 1. Лике~аз/юэллкг и ои~>асье Специалисты, работающие пад программным проектом, за. полняют анкеты, предоставлял информацию о реальном ходе проекта. Для офици. альпой анкеты ответы уточняются во врслгя индивидуальных интервью. 2. Эюпногрлфичсские игсаедования. В главе 6 уже обсуждалось, как этнографические исследования примсшпотся для изучения процесса разработки ПО в контексте человеческой Леятельпости. Благодаря этому типу анализа раскрываются все тонкости и сложности, недостижимые для понимания в случае применения других методик.
Кажды!1 из этих подходов имеет свои достоинства и недостатки. Если правильно составить вопросы, анкетирование поможет провести анализ сравнительно быстро. И наоборот, некорректно о]юрмулированпые илп певерпыс вопросы привсдуг к созданию неправильной модеян процесса. Кроме того, такой анализ имеет много общего с оцениванисм. Поэтоьй опрапшваемые могут не сказать правду и даже дать те ответы, которые, по их мпеппю, будут желательны проводящему опрос.
Этнографический эпалпз па первый взгляд даст более верпыс результаты. Однако эта процелура достаточно длительная и кропотливая, опа может продолашться несколько месяцев. Кроме того, здесь г!аппгае основаны па внешнем наблюдении за процессом. Полный анализ происходящего должен проводиться с самой начальной стадии внедрения проекта и до поставки готового продукта заказчику н его последующего сопровождения.
Это может оказатьса непрактичным, так как график внедрения некоторых проектов растягивается па несколько лет. Поэтому этнографический анализ принесет больше пользы прп дс. тальпом рассмотрсшш отдельных фрагментов процесса производства. 25. Совершенствование производства ПО 519 Таблица 2$.2. Элементы модели процесса создания ПО Описание Элемент модели Имеет четко поставленную цель, определены вход" и "выход" действия. Примеры действий: подготовка тестовых данных для тестирования модулей, нашюа- нис кода функции плп модуля. редактирование доку- ментов и т.п.
Обычно действие представляет собой элементарную часть этапа процесса, выполняется од- ним человеком или группой и ис может быть разбито на более мелкие действия Действие (изобрюкается прямо. угольником с закругленными краями без тени) Состоит нз набора действий, связанных между собой и решающих общую задачу. Примеры этапов: анализ требований, проектирование системной архитекту- ры, планирование тестирования системы и т.д. Это реыьный результат действия или этапа, прсду смотренный планом проекта Этап процесса (изображается прлмоугольником с закругленны- ми краями и с тенью) Коптролы<ый проектц ый элемент (изображается как прямоугольник с тенью) Может быть либо прсдусловием и соблюдаться до на- чала вьшолненил этапа или действия, либо постусло.
вием, которое должно выполшгться после окончания действия или этапа Условие (изображается паралле- логралшом) Очерчивает область ответственности лиц, работаю. щпх пад проектом. Примеры ролей: менеджер по кон- фш>рации, специалист по тестнроэашио, проекти- ровщик ПО и т.п. Несколько ролей мог>.г выполняться одним и тем же специалистом, так же как и одна роль можег быть разделена между несколькими лицами Роль (изображается в виде круга) Результатом анализа можно считать модель производственного процесса любого > ровня детализации. Модели процессов, приведенные в качестве примеров в этой книге, слишком абстрактны и упрощены, чтобы представить общую картину рассматриваемого процесса.
На таком абстрактном уровне производственные процессы в разных организациях кажутся похожими. Однако, в зависимости от типа разрабатываемого программного обеспечения и рабочей среды организации, типовые модели детализируются и принимают определенный конкретный вид. Для первоначального обсуждения процесса разработки типовая модель незаменима. Однако информации, которая в ней содержится, нс достаточно длл анализа процесса и внесения изменений. Для совершенствования процесса необходимы данные об этапах разработки, выходных результатах каждого такого этапа, персонале. качестве коммуникаций, графике работ и других компонентах деятельности орппшзации по реализации про. екта, так как все это может повлиять на создание ПО и должно быть учтено в модели про.
изводственного процесса. В табл. 25.2 описаны элементы, входящие в состав детализированной модели технологического процесса созлания ПО (с указанием, как эти элементы изображаются на схеме модели). 520 Часть т'1. Управление Окончание табл. 25.2 Элемеитмодели Описание Исключение (в приведенном ниж- ее примере не присутствует, изо- бражается в виде ромба) Это описание способов изменения технологического процесса в случае возникновения ожидаемых либо непредвиденных обстоятельств.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
