Гертовская Ирина
Председатель программного комитета - ЛАФ
Moscow, Russia

В разработке ИТ-систем много лет. Роли: аналитик, разработчик, менеджер, руководитель проектов. Экс-зам.директора Производственного департамента ОТР-2000. Соавтор профессионального стандарта РФ "Бизнес-аналитик", автор курсов для аналитиков.

Любимое: анализ и проектирование, организация работ аналитиков, их обучение. 

Докладчик конференций Analyst Days, SECR, ЛАФ, Точка сборки.

Talks (10)
  • 10.09.2021
    Find the analyst's error

    The workshop is intended for practising requirements revision skills, following up on the talk "Ways of requirements revision". 
    In a team game, we will try to reduce the project costs for fixing the most expensive errors -  analysis and design errors. We will learn how to check the completeness and consistency of requirements, taking into account the typical mistakes of analysts. We will play the game of requirements agreement by testers and practise the ability to argue the need for correction.

    • Average
    • 1h 30 min
    • SQA Days / 29
  • 10.09.2021
    Ways of revising requirements

    Steve McConnell, in his book 'How Much Does a Software Project Cost' and World Statistics, tells us that it is most expensive to correct bugs made during the requirements gathering and design phases. Sometimes the bugs detected are serious enough to require redesigning not only your system (or some part of it) but also related systems. When these bugs are detected at the testing stage, the work of analysts, developers, testers and technical writers goes in the bin. 

    Can we identify at least some of these bugs at an earlier stage of work? Can a tester (requirements engineer) detect bugs in requirements before software development? 

    We will look at one of the fundamental properties of requirements: completeness, including CRUDL. We will see how we can check this property.

    • Average
    • 20 min
    • SQA Days / 29
  • 22.01.2021
    Assessment of competencies as a tool for the development and involvement of the analyst

    In chat rooms and analyst groups, questions often arise: 

    • How to assess the competencies of analysts?
    • What competencies should a middle analyst have, what should a senior analyst have? 
    • How to assess competencies? How to understand what competencies are lacking? 
    • How to explain the assessment result to a person without offending him/her? 

    I'll tell you about how we built a competence assessment system, assessed analysts, and obtained a tool for developing specialists and assistance in securing project work. And how to build a similar system for your needs in 5 steps.

    The talk is based on the real experience of working as the head of the systems analysis department in a large IT company. Many employees have grown from Juno to lead analyst, became heads of departments, project managers, chief specialists, architects. It will be of interest to both resource managers of analysts and analysts consciously seeking their own professional development.

    • Hard
    • 40 min
    • Analyst Days / 12
  • 21.10.2020
    How to learn the subject area quickly

    The quality of functional testing largely depends on the tester's knowledge of the subject area of the SOFTWARE being tested. There are a lot of subject areas, sometimes they are complex, sometimes very complex, and you need to test them. In this report, I will share techniques for rapid immersion in a new subject area. I will tell you what points you need to pay special attention to when testing the functionality of complex systems.

    • Average
    • 40 min
    • SQA Days / 27
  • 15.06.2020
    How to think and work systematically?

    As a follow-up to Anatoly Levenchuk's report, we will talk about the application of systems engineering and system management methods based on systems thinking. How these methods help improve quality in the design and implementation of complex systems, reduce overhead and accelerate design work. Sergei Pchelyakov will share an example of how, with a lag of 20% in the middle of the project, using these methods, he managed to finish the project successfully, reducing the term by almost 20%.

    • Average
    • Analyst Days / 11
  • 30.11.2019
    "How to avoid the trap". About impacting of non-functional requirements on the system's performance

    Business digitalization, merging of business and IT leads not only to the growth of functionality of IT systems but also to criticality for a business of availability, reliability, the safety of IS. Let 's talk about how an analyst can and should influence such properties of IT systems, that is, non-functional requirements, their identification, application, reflection in project documents. Let 's look at the main classifications (international, state, industry) and scenarios of quality attributes, their application in the work of analytics. The report is based on its own experience. I will share my vision of the analyst 's work checklist to ensure the system is operational.

    • Hard
    • 40 min
    • Analyst Days / 11
  • 28.02.2019
    Immersion in a new domain, analyst checklist

    Many of us are familiar with the situation: the customer received a request for a presale, an urgent task for analysts, an opportunity to conclude a promising contract, but there are no experts among the Company's analysts in this subject area. Is this a reason to refuse a deal? Or is there a way out?
    At the workshop, I will share my experience, how in a few days I immersed myself in a new domain, what problems arose and how they were solved. We will discuss examples of successful and unsuccessful experience and the reasons for failures. Consider using the method of mental maps (Impact Mapping), as a way to determine the boundaries of the project and the main hypotheses created by the joint efforts of the developer and the Customer. Together, we will develop a checklist of analyst immersion in a new domain.

    • Average
    • 1h 30 min
    • Analyst Days / 10
  • 31.12.2017
    From scratch and turnkey

    The analyst's participation is necessary at every stage of software development, from survey to implementation. At the master class, we will review the entire software development process and the role of the analyst at each stage. Let's talk about what sources of information are used by the analyst at each stage, what results are obtained and how they are applied in the future. What you should see, take into account, provide for the successful development, implementation and operation of the software. Consider the typical problem points and resolution paths. Of course, in an hour and a half, it is impossible to consider the details, but we will have time to highlight the main stages, discuss the goals and results of each stage.

    • Average
    • 1h 30 min
    • Analyst Days / 8
  • 31.01.2017
    Assessment of labor costs of the analyst: practice of application

    The topic of the talk was inspired by discussions in close circles of analysts  - is it possible to assess the labor work of analysts and clearly defined turnaround time? It will be demonstrated which assessment methods of labor costs and the dates of performance of the work of systems analysts we use in our daily practice. 

    This talk is not for you if you have:

    - experienced analysts who are able to assess own the dates of performance of the work with precision acceptable by a project manager;

    - diversified,  often research works;
    - innovative directions of works, mostly brainstormings and researches.

    • Hard
    • 40 min
    • Analyst Days / 6
  • 25.02.2015
    Management functionality and interface requirements related systems

    Information system of a large industrial enterprise or a government department consist of several software systems. Also these software systems interact with other organizations software systems. For various reasons, changes to the software is the constant necessities of life. Inconsistent changes of software systems have a risk of stopping work the Information System and the enterprise (the organization, the government department) in whole. The report describes the sample of the management functional requirements of the automated system. We explain about changing the documents, the system operation on the documents, the user operation on the documents and the interfaces of exchanging document between subsystem. We suggest the requirements storage structure and the methods of monitoring changes in adjacent subsystems. Change monitoring allows stable operation of an organization. In additional the system requirements management makes it possible to generate project documentation.

    • Average
    • 40 min
    • Analyst Days / 4
To leave a feedback you need to

Chat with us, we are online!