Every methodology has its own limits of applicability. It's important to understand these limits, watch them in dynamics and foresee the moment when current methodology becomes ineffective for a particular project.

The talk gives an overview of modern methodologies and their upsides and downsides. I give an example of developing own methodology and give many practical advices.

When starting to work on a brand-new, fairly complex project, it’s very important to get to the same page in the sphere of business rules formalization. One of the universal solutions to this problem is a system of Business Rule Engine – the rules to build new business rules for a project. More formally, Business Rule Engine is a set of several Doman-Specific Languages along with the rules for their development and interaction.

How to segregate parts of system that are suitable for formalization via DSL ?

What kinds of DSL are there? How to describe the grammar of these DSLs? What specialists should be involved in DSL formalization and when?

What types of DSL suit the requirements best? Will the grammar of these DSL change over project lifetime?

What methodology (Waterfall, Agile) suit best when working out project business rules?

A rich set of real-life project examples is given.

Every methodology has its own limits of applicability. It's important to understand these limits, watch them in dynamics and foresee the moment when current methodology becomes ineffective for a particular project. The talk gives an overview of modern methodologies and their upsides and downsides. I give an example of developing own methodology and give many practical advices.

When the application is released into the real lifecycle (to the end-user PCs), in a long run prospective, the problem of real-time quality assurance and support arises. The problem includes monitoring of such important application indicators as crashes, hangs, eating up too much CPU, eating up too much RAM and other more specific indicators.

"Main goals of these observations" are tracking these indicators in dynamics, spotting down and reacting to unnatural indicator spikes, that eventually leads to higher quality and more reliable software.

The report suggests a solution for monitoring indicators and tracking defects down with minimal time and human efforts. The solution is based on taking and analyzing process memory dumps.

The suggested solution is relevant to native desktop applications.