So for those of you who don't know me, I'm Igor Oya. I work for the CTA central organization,

the project office. My role in the organization is the coordinator of the array control and

data acquisition work package. The name already tells you what this software should do, but

I have one slide later about this. So the idea is to share in this presentation what

is our strategy for the software developing lifecycle. And this work is based on the work

of the people which I'm listing below here in the title slide. So, okay. So why do we

need the software development lifecycle? Well, we want to define which are the activities

and the roles in the implementation of a software product. We also want to have, especially

in big projects, that the product is of good quality and meets the requirements and the

schedule. Something which for me is interesting to share, and of course, all of you which

are experienced, you know, but maybe the younger people are not aware, is that the main cost

of the software is not implementation cost. Not at all. The biggest cost in the total

life of a software product is the maintenance by far, but there is a big cost also in designing

efforts. We should have big effort also in testing aspects. And another thing is that

we are not careful in all these aspects. And especially if we don't maintain our software,

then the software, what you call the software rots, right? It becomes less and less manageable

because you don't know, you start to introduce changes and at some point, you can see one

example, an illustration of the productivity you may have if you are not careful with your

software product. Eventually, no one is able to change the line of code and you need to

drop it. So the idea is to have a life cycle which we can deliver software which is also

easy to maintain. And what I'm going to present here is often confused by our upper management

in our project and this being recorded, so I will just say general statements that sometimes

it's mistaken that the development life cycle is a development schedule and we really need

to speed these two things. All things are important. Another thing that rule of thumb

is that the software maintenance cost is from about 10% of the total cost yearly if you

want to keep the software in good state. Of course, it's not exact cut but just to get

an idea and this is something very important to transmit to the management. It's not about

building the software and then it just runs for 30 years. We all know that there will

be always feature needs, feature requests, but you also need to maintain your software,

fight against the obsolescence, make sure that the software is secure and all of these

things. Okay, so there are many software life cycle approaches in the industry. When I first

started many years ago to do software, I was tasked to do some software for the magic telescope

for data quality check and what I did is I just coded, see if it works. If it does not

work, I change it. So code and fix this is really most basic thing. Obviously, this is

not something that you can do in a big project and there are many, many approaches from the

very traditional waterfall to many others and I won't list them because I'm sure we

are going to hear some approaches during the session. Maybe just to pick the classical

example of the waterfall model which is something which usually big projects, the upper management

are very comfortable with because it also matches properly with what you do with hardware.

You basically have these following phases. You have requirements analysis, you want to

write what is needed for your software, then you do your design, you know, your architecture,

your interfaces, then you go and you do implementation and testing of the software, then you do the

integration with the subsystems, you test that everything fits together, then you want

you operate and if you need to do some upgrades, you can go back and we know that this work

in this way is very difficult in practice for a software project but what is interesting

from this model is that basically any software lifecycle you may imagine will have more or

less these different phases but organized in a different way. Of course, we have AYAL

and this is what many, many industry and I'm sure we will listen afterwards to our projects,

for example, from SKA using AYAL frameworks and there are different approaches like strip

programming, scram, this is of course AYAL approaches something I personally like very