Рекомендации по использованию книги

из "Методы управления проектированием программного обеспечения "

Предположим, что в некоторой организации возникла необходимость приобрести для своих нужд или, наоборот, предложить кому-нибудь универсальное программное обеспечение. Вполне возможно, что эта необходимость возникнет впервые. Как же тогда выбрать поставщика или потребителя Примером выгодного покупателя программных средств может служить любой университет. Сознавая, что ЭВМ. становятся все более необходимыми в повседневной деятельности, многие университеты уже не рассчитывают больше на то, что их собственные факультеты вычислительной техники будут в состоянии самостоятельно обеспечивать необходимое обслуживание учебного процесса с помощью программных средств, являющихся побочным продуктом их исследовательской деятельности. Университеты осознают, что нуждаются в стабильных и надежных средствах и, чтобы их иметь, должны применять современные методы управления, обоснованно выбранную аппара-ТУРУ и универсальное программное обеспечение. [c.18]
Некоторые из приводимых в книге методов и средств могут реализовываться по выбору или должны приспосабливаться к конкретным условиям, и такие случаи оговариваются по ходу изложения. В то же время, если для решения той или иной проблемы твердо рекомендуется какой-то определенный метод, автор показывает, что все известные альтернативные решения оказываются хуже. В книге содержится много полезных методов и средств, но их не обязательно внедрять все сразу. На вопрос о том, какие из них следовало бы опробовать в первую очередь или в каком порядке вводить, нельзя дать однозначного ответа. Можно лишь дать несколько рекомендаций. [c.19]
Если применение предлагаемых методов и средств начать с иерархической декомпозиции планов и проектов создания программных изделий, то легко удается реализовать и все остальные концепции. Основой хорошего структурирования разработок является генеральный план — соглашение о требованиях, в котором четко устанавливаются еще до начала проектирования стратегия и тактика создания изделия. В приложении приводится пример такого документа. [c.19]
Хорошее изделие может быть создано только на основании хорошего проекта, а для этого требуется хорошая документация, которая понятна разработчикам и удобна для использования в процессе проектирования. В том случае, когда проектные решения должны быть поняты большим числом людей, которые должны общаться между собой в ходе проектирования универсального программного обеспечения, качество проекта полностью определяется качеством положенной в его основу документации. Поэтому, чтобы успешно производить программные изделия, необходимо иметь полную документацию, охватывающую все аспекты их разработки. Вслед за принятием на вооружение соглашения о требованиях нужно позаботиться о том, чтобы спецификации изделия отражали потребности всех связанных с его созданием функциональных групп разработки, испытаний, выпуска документации и др. Обеспечить такое соответствие нетрудно, внедрив в практику проектирования программных изделий после соглашения о требованиях внешние спецификации, описываемые здесь достаточно подробно. [c.19]
Имеются весьма основательные доводы в пользу отделения друг от друга некоторых из функций, правильное выполнение которых способствует успешному выпуску изделия. К тому времени, когда почерпнутые из этой книги методы и средства будут введены в действие, такое разграничение функций наверняка можно будет реализовать. И тогда следует удовлетвориться, что группа испытаний работает независимо от группы разработки и потому не подчинена и не может ей подчиняться. Затем следует обособить функцию обслуживания, которая должна в равной степени охватывать обеспечение нормальной деятельности всех остальных групп. При этом, однако, нельзя забывать о планировании, организации поддержки, документирования и сопровождения программных изделий в целях лучшего удовлетворения потребностей пользователя. Если потребности пользователя изменяются, следует без колебаний преобразовывать и эти функции. Приняв такую стратегию, можно-смело приступать к более полной реализации принципов проектирования программного обеспечения и применять методы управления этим процессом точно так же, как их применяют в целом или по частям преуспевающие. руководители. [c.20]

Вернуться к основной статье