Главы из книги Сергея Орлика и Юрия Булуя «Введение в программную инженерию и управление жизненным циклом» (базируется на SWEBOK).
От автора: о чем эта книга
В течение десяти лет работы в Borland мне постоянно приходится обсуждать с менеджерами, аналитиками, архитекторами и разработчиками вопросы применимости тех или иных продуктов, технологий, проектных решений. Последнее время, все чаще темой дискуссий становится процесс разработки программного обеспечения, как таковой, вопросы организации проектных команд, адаптации стандартов и подходов в управлении жизненным циклом ПО к сложившейся культуре разработки, и наоборот, трансформации существующей культуры и ценностей в новое качество. Приходится вспоминать и кое-что из опыта «прошлой жизни», когда я сам выступал в роли корпоративного разработчика и лидера проектной команды. Приходиться применять и уже более «свежий» опыт разработки рекомендаций по процессу разработки и внедрению технологий управления и поддержки жизненного цикла разработки приложений. И самому приходиться постоянно совершенствоваться, в том числе помогая другим.
Для кого эта книга
Для всех, кто связан с индустрией информационных технологий. Только не подумайте, что речь идет только о разработчиках и менеджерах проектов в области программного обеспечения. Конечно, нет. Ведь если в вашей деятельности программные системы играют серьезную роль в качестве повседневного и необходимого инструмента обеспечения вашей профессиональной деятельности, вы, наверняка, сталкиваетесь с вопросами взаимодействия с ИТ-специалистами. Вам, как пользователям и заказчикам просто необходимо иногда вникать в проблематику разработки программного обеспечения, если, конечно, вы хотите получить результат. Вы, кто создает (в общем смысле этого понятия, ни в коем случае не ограничиваясь только вопросами кодирования), поддерживает и развивает программное обеспечение, наверняка, найдете нечто новое в этой книге. Вы школьник или студент — вы учитесь. Не останавливайтесь. Эта книга и для вас. Хотя бы потому что это еще одна точка зрения. А две головы, иногда, лучше, чем одна. Так что, книга, как это принято иногда говорить — «для широкого круга читателей», для кого использование компьютера в повседневной работе не является абстракций, но полнофункциональным инструментом.
 Автор: Сергей Мартыненко
Не знаю почему, оценку рисков часто именуют «Управлением рисками». Да эта процедура является составной частью риск менеджмента. Одной из самых простых. Но ведь часть не может быть целым, не так ли? Это примерно, как показывать на колесо и с гордостью говорить: «От мерседеса», или еще хуже «Это и есть мерседес». Однако такая практика достаточно распространена.
Менеджер, на основании своей экспертной оценки выводит некое значение риска, как правило, одно единственного. И на этом все заканчивается.
 Автор: Вячеслав Панкратов, Новичков Александр
Материал опубликован в журнале «Стратегия IBM в области программного обеспечения». №1, 2007 год. (PDF, 2mb)
Мы постарались изложить относительно новую методологию внедрения инструментария автоматизации разработки ПО. Ее не следует рассматривать как заключительный этап «классического» консалтинга, которому предшествуют многомесячные исследования текущего состояния дел в подразделениях по разработке и внедрению информационных систем, но мы предлагаем использовать ее в качестве продуктивного инструмента внедрения процессных изменений.
 Автор: Вячеслав Дукальский
В отличие от традиционных подходов к управлению разработкой ПО, включающие в себя детальные планы, диаграммы, расписания, тестовые спецификации и прочие документы, которые с избытком научились производить менеджеры проектов еще до того, как проект начался, Scrum предлагает вести проект своим оптимальным курсом, раскрывая все технические подробности уже в ходе этого пути.
По мере усложнения проекта, конечно же, усложняется и его управление. Хорошо, если задачи всем понятны, или же есть уже опыт выполнения подобных проектов. В этом случае применение определенных (теоретических) моделей разработки может оказаться успешным. Но что делать, если задача слишком сложна и не до конца всеми понята? Очень часто центральное планирование в этих случаях начинает давать сбои, либо вообще приходит в негодность. К примеру, вы едете на автомобиле, и начальство дало вам карту с указанием маршрута и указав время прибытия на каждом перекрестке. Вы выдерживаете график, но вдруг перед вами произошло ДТП и образовалась большая пробка. Вы, не можете объехать этот участок по другому маршруту, потому, что у вас есть карта и маршрут, по которому вам предписали следовать. Вы, возможно, позвоните начальству с просьбой составить новый маршрут и вам его составят, утвердят и вышлют. Но это может занять много времени и возможно, пробка к этому времени уже рассосется и вам будет удобней следовать по старому маршруту. Маршрут, который вам предоставили, был верный, но не учел непредвиденные обстоятельства — большая пробка в результате ДТП. Бывают случаи, когда и маршрут сам по себе неправильный, например, вам нужно свернуть, но дорожный знак запрещает вам это сделать. Вам снова необходимо звонить начальству и утверждать новый маршрут. Гораздо более эффективно было бы предоставить вам большую свободу и право самому выбирать наиболее удобный и быстрый маршрут, указав только конечную точку. Важно также предоставляя свободу, очерчивать границы этой свободы, поскольку есть опасность скатиться к анархии и сделать проект неуправляемым. Решить все эти проблемы вам поможет Scrum.
 Автор: Константин Берлинский
Справочник удачных проектных решений при разработке ПО
Войны ИТ-методологов не затихают. Каждые несколько лет нам преподносится совершенно новая, быстрая, легкая, простая, эффективная методика (или новая версия «старой»). И уж она наконец-то решит главную проблему — построение качественного ПО в срок.
Я думаю, что правда о методологиях заключается в том, что их не существует...
Есть лишь УПР — удачные проектные решения — которые могут сработать (или нет) в конкретной ситуации и проекте. Цель этого справочника — собрать их вместе, дать им краткое описание, и подвигнуть ИТ–сообщество к дальнейшему их поиску и классификации...
 Автор: Вячеслав Панкратов
Материал впервые опубликован в журнале «Открытые Системы» #02/2007 Сегодня много говорится о качестве программного обеспечения и информационных систем, проводятся исследования, демонстрирующие зависимость качества и эффективности автоматизируемых бизнес-процессов. Качество программного обеспечения из абстрактного и неосязаемого понятия преобразуется в комплексную метрику оценки программного решения, проекта его внедрения, процесса создания и уровня использования информационных систем в целом. От чего же зависит качество программ и как можно на него влиять?
 Автор: Руколь Наталья
Пролог, или история разработки новейшего продукта ХХХ
Январь, Стадия проектирования:
Бизнес-аналитик: нам обязательно нужны и GUI и веб-интерфейс, потому что это атрибуты всех современных серьёзных приложений
Архитектор: Так же нам обязательно нужна командная строка с возможностью удалённого доступа – это признак профессионализма
Март, Разработка
Архитектор: мы будем писать наше приложение на Java и ActiveX, потому что они scalable.
Руководитель разработки: нет, мы будем писать на C# потому что он более secure и очень reliable
Сентябрь, Тестирование
Тестировщик: я настаиваю на том, что это критикал, потому что программа падает при нажатии на эту кнопку всего шестнадцать раз подряд!
Разработчик: сейчас это нельзя исправить потому что класс MegaPuperClass библиотеки Refactored_on_May не поддерживает обработки исключений
Декабрь, Эксплуатация
Пользователь: очень симпатичный калькулятор, но я не понимаю, как им пользоваться?
Если ничто из вышеперечисленного диалога Вам не знакомо – видимо, Вы не участвовали в разработке софта  .
 Автор: Дмитрий Ручко
Данная статья была подготовлена на основе доклада, сделанного автором на конференции SQA-2 (http://sqa2conf.blogspot.com/) в октябре 2007 года.
Целью данной статьи является желание дать людям верное представление о том, что же такое «автоматизированное тестирование» и с чем его «едят».
Введение
С давних времён человечество занимается мифотворчеством. Чем меньше имелось знаний об окружающей природе, тем сильнее были заблуждения человека и удивительнее его мифы. С развитием науки область знаний расширилась. Но и область неизвестного стала больше. Старые мифы ушли, но появились новые.
В данной статье я хотел бы рассказать об автоматизированном тестировании и связанными с ним заблуждениями. Часть из них больше свойственна менеджерам верхнего звена, часть – рядовым сотрудникам. Но и те и другие мифы мешают правильному пониманию и развитию данной технологии как таковой и её успешному внедрению на местах для обеспечения более высокого качества выпускаемых продуктов.
 Автор: Владислав Орликов
Оригинальная публикация
Сэкономил – значит заработал, – утверждает пословица.
Подобного мнения придерживаются руководители софтверных компаний, стремясь сократить неявные производственные издержки. Хотя многие из них не заметны на первый взгляд, они вполне ощутимо сказываются на финансовом результате. К числу неявных издержек относятся повышенные затраты из-за неэффективного тестирования разрабатываемых программ.
Всякая более-менее значимая модернизация программного кода требует перепроверки его функционирования. Применяемые для этого испытания часто являются типовыми и могут многократно повторяться в последовательных циклах модернизации программы. Это утверждение верно и для настольных систем, и для «тяжелых» информационных комплексов – от веб-порталов, играющих представительскую роль, до систем финансового учета. Видимо, поэтому все больше руководителей осознают актуальность автоматизированного тестирования, о котором пойдет речь в этой статье.
 Автор: Гринкевич Сергей
Статья написана по мотивам доклада, сделанного автором на конференции “Российские Интернет технологии 2007″ (РИТ2007) в апреле 2007 года в Москве.
Оригинальная публикация
Краткое описание:
В отличие от программирования, тестирование не создает прибавочной стоимости, т.е. проведение тестирования напрямую не влияет на ценообразование. Потратите вы 1000 или 1.000.000, это никак не отразится на ценности программы для пользователя в момент ее покупки. Осознание уровня качества приходит к пользователю позже, с опытом использования программы. Как следствие этого факта, многие руководители отказываются или максимально урезают расходы на такие «не профильные» активности, как тестирование. Но существует граница за которой расходы на тестирование просто бессмысленны. В этой ситуации лучше пользоваться принципом «либо все, либо ничего». Половинчатые решения всегда экономически не оправданы и влекут за собой неэффективные траты бюджета проекта.
В чем заключается экономическое обоснование необходимости тестирования программ?
Какой набор тестовых активностей минимально достаточен?
Что нужно делать, чтобы управлять процессом и, следовательно, бюджетом проекта?
Эти и другие вопросы я постараюсь осветить в своей статье.
|
