Каждая из методологий разработки ПО вместе со своими достоинствами и недостатками имеет определенные границы применимости.

Важно понимать эти границы, отслеживать в динамике и предугадывать моменты времени, когда текущая методология становится неэффективной в рамках конкретного проекта и конкретной команды.

В работе представлен обзор различных "трендовых" методологий, их плюсы и минусы, переходы между методологиями и т.п.

Рассматривается опыт разработки собственной методологии и даются практические рекомендации.

При построении нового, достаточно сложного проекта с нуля, очень важно с самого начала прийти к общему знаменателю в области формализации требований. Одним из универсальных решений этого вопроса является система Business Rule Engine - то есть, правила построения новых бизнес-правил на проекте. Более формализованно, Business Rule Engine - это набор нескольких Domain-Specific Language (DSL) вместе с правилами их развития и взаимодействия. Как правильно выделить те части системы, которые подходят под формализацию через DSL? Какие типы DSL существуют? Как описать грамматику этих DSL? Каких специалистов и на каком этапе проекта для этого нужно привлекать? Какие типы DSL лучше подходят под требования? Будет ли DSL претерпевать изменения грамматики с развитием проекта? Какая методология (Waterfall, Agile) больше подходит для проекта на стадии формализации требований и в каких случаях? Рассмотрение ведется на конкретных примерах из реальных проектов.

Каждая из методологий разработки ПО вместе со своими достоинствами и недостатками имеет определенные границы применимости. Важно понимать эти границы, отслеживать в динамике и предугадывать моменты времени, когда текущая методология становится неэффективной в рамках конкретного проекта и конкретной команды. В работе представлен обзор различных "трендовых" методологий, их плюсы и минусы, переходы между методологиями и т.п. Рассматривается опыт разработки собственной методологии и даются практические рекомендации.

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

"Цель таких наблюдений" - отслеживание показателей в динамике, выявление и реакция на отклонения показателей от нормы, и как следствие - более высокое качество и надежность приложения.

В работе предлагается решение для мониторинга показателей и выявления дефектов, основанное на снятии и автоматическом анализе дампов памяти процесса.

Решение дается в применении к "родным" декстопным приложениям.