Another review of another course. Or how I studied as a system analyst at Netology

Why did I even get involved in all this?? Well look. I work as a technical writer and, in addition to preparing user documentation, I also have to perform the following tasks:

• describe the architecture of some system component or microservice,

• describe AS IS processes, update documentation on them,

• make changes/update descriptions of analytical models and data structures,

• make changes to the API specification,

• describe data flows, etc. etc.

At the same time, the developers also had to draw all sorts of UML diagrams and even set small tasks in Jira for some bugs that I discovered while preparing technical documentation.

So I thought: “Since I’m so close to the systems analyst, why not get even closer to him?” And then the company also collected applications for external training. In general, I looked, compared and chose “Netology”.

11 modules in 10 months and a professional training diploma in my hands

So, the course includes 11 modules (I don’t take the module with introductory information for students into account) plus a bonus English language course for analysts (I won’t talk about it). Some of them seemed very easy to me, while others still required some effort. I'll tell you a little about each of them.

Module “Software Development Life Cycle”

From the name it is clear that the software life cycle was studied here. In addition, while completing the module, we became acquainted with Agile, Scrum and other modern, fashionable and useful things.

If you don’t know anything about this, I think the module will be super useful. If you have come into contact with this, the module will help you repeat the theory, systematize and put everything in order.

Module reporting form – test. There are no supernatural things in the test: if you have studied all the materials within the module, you can pass it easily and quickly.

Did I like the module? More likely yes than no. It’s always interesting how software development methodologies are seen and interpreted by others (you must admit, it’s not always possible to find a consensus on some things).

Module “Working in an Agile Project Team”

It is clear that here we learned to work in an Agile team. Here we learned to use Miro, conduct domain analysis, etc.

In principle, the module turned out to be useful. We worked as a team during the webinars. But I have questions for my homework. Here you do your homework “in one person” (there was ICE scoring, sprint planning, etc.). I would like for students to be divided into groups to do their homework, so to speak, to immerse them as much as possible in team work and to correspond to the name of the module. But it is what it is. It still turned out pretty good.

Requirements Analysis module

It turned out to be a rich and useful module. Here I learned about Wiggers and Beatty (I bought their book “Software Requirements Engineering” and read it – I liked it).

The module is quite rich, it was not boring. There was a lot of usefulness and practice. As part of it we studied:

• Working with requirements (what they are, how to collect them, formalize them, how to manage changes, etc.).

• Business canvas model. I think that this is more about business analysts, but it wouldn’t hurt for a CA to know such things (especially since it often happens in our country that everyone is responsible for everything :)).

• User stories and job stories.

• UML and different types of diagrams.

We can say that this module is largely based on exactly what Wiggers is trying to convey to us. Go through it “bite-by-bit” with a book and everything will be clear.

As part of the final work for the module, we practiced drawing up formalized software requirements, made a diagram of use cases, and prepared text descriptions of VIs.
It wasn't bad. I liked it and think the module was a success.

Module “SQL and data retrieval”

This is just the bomb!!!

I had worked with SQL before (I was preparing user documentation for a domestic in-memory DBMS) and thought that I had solid knowledge of SQL.

But this module made me understand that my knowledge is not entirely solid. Probably, it all depends on the teacher and we were lucky that we came across Nikolai Khashchanov. It is clear that the man is a true guru in his field, understands everything down to the smallest detail, knows how and loves to teach it.

This is probably one of the best modules of the course and the one that I got the most out of: a lot of knowledge and fun. But it was a bit difficult, I’ll tell you: I just remembered what it was like to sleep at night and do homework, and then work with red eyes.

The final module is done. I thought it was really good. But the curator gave me the bumps.

Module “Interface Prototyping”

Well what can I say? Here they teach you how to work with Figma. They give some basics of UX/UI.

I've worked with Figma before. But I also learned something useful from the module: I learned how to create clickable prototypes (I had never done this before). Actually, this was the final task when passing the module.

Module “Business Process Modeling”

Again, I think this is more about business analysts. But SA won’t be superfluous either.

What we studied:

• BPMN, of course

• data flows and DFD diagrams,

• IDEF family notations.

As part of the final work, we drew IDEF0 (for the top-level description) and a BPMN diagram to describe the business process.

It was interesting. Because I haven’t dealt so closely with BPMN before, I think that I learned a lot of useful things from the module.

Module “System Integration and API Documentation”

I'm a technical writer who specializes in documenting APIs. I thought that I wouldn’t learn anything new here. But no. I liked how they teach HTTP API design here (let's call it REST-like).

There was a module about SOAP. In my opinion, it has undeservedly received less attention than the REST style. I would like more information and practice specifically on SOAP.

I would especially like to note the lesson on ensuring REST API security. I really liked how they handled OAuth2.0/OIDC.

As part of the final work on the module, we designed an API and prepared a specification for it in the OpenAPI format.

Module “Software Testing and Deployment”

Honestly, I would like to characterize this module as “bare theory”. We sorted out testing levels, principles, techniques… We also included introductory information about DevOps.

The module needs some work. Yes, we are not training testers here, but we would like more practice.

Module “Documentation in IT projects”

A module from which I was mistaken :). I thought: “Well, now it will open, and I, as a technical expert who knows how to do docs as code, knows SSG and other smart words, will quickly go through it” But no. Everything was different.

The module focused on working with SRS. And it was really cool. I liked it. We touched a little on GOSTs and other standards, CJM, etc.

The final work is the development of a small SRS. I really liked it, it was interesting, useful (and a bit difficult at first).

Final module

In the final module, it was necessary to prepare a specification of software requirements, as well as develop and describe an API. In general, we can say that this was a work based on the previous module (from fresh memory, so to speak), but more voluminous and serious.

Students were assigned curators to whom they had to defend their work. Everything went somehow easily for me: at each iteration the curator did not make any significant comments, everything went smoothly and comfortably. Then the defense happened, and then my professional training diploma came to me.

What's the result? Do I recommend the course? Yes, I recommend it. I think I learned a lot from it that was useful to me. It wasn't very difficult (except for some modules). But this is probably because I already have some experience in this IT of yours. If I were immersed in the profession from scratch, I’m sure I would have to work harder.

I have everything. Questions, complaints, comments?