Postado em 06/2020
De acordo com Association of Computing Machinery, engenharia de software é a aplicação sistemática de abordagens de engenharia para o desenvolvimento de software. Podemos pensar como engenharia de sistemas seguida por uma atividade de desenvolvimento orientada para o processo, certificando-se de que o que foi especificado e projetado é o que é entregue.
Certamente, a engenharia de software é uma disciplina de engenharia. O processo de compreensão das especificações, determinação da arquitetura, implementação e teste tem muitas semelhanças com outras disciplinas. Embora também tenha muitas diferenças, por exemplo, a maior parte do trabalho pode ser concluída sem fabricação física.
A escrita de software costuma ser chamada de construção e, portanto, comparamos com as fases de fabricação ou construção em outras disciplinas. But if we take a closer look, it is not construction at all, it is all design. Engineers write software designs in code, and computers do the building, whether by compiling it or directly interpreting.
In software, there is no manufacturing line. Building the final component is cheap, and replication of that final product is both perfect and free. Many designs in other disciplines either take longer than originally estimated, cost more, or simply never see completion.
Also, there are different types of software engineers just like in other disciplines. A software architect can design the overarching system, detailing what kind of communications are between entities. Once the overall system has been designed we then go down to application-level software development.
Different disciplines have different degrees of rigor in their processes. Process and standard oriented development is generally expensive, so many enterprises choose varying degrees of rigor in their development.
There is a significant effort that goes into the design of systems, trying to make every stage in its life cycle management. A well-designed system can allow a small team to perform even large overhauls in a manageable way.
Software can provide incredible value, and the best applications are constructed with high standards of quality, akin to the sort of construction one would expect from automotive or civil engineering. However, In general, the software engineering lacks many aspects of other disciplines, which gets in the way of projects.
Standardization and work item breakdown has certainly improved, but the design constructs still are not there to create out a large system. In some ways, software engineers can not even agree on what is needed for a given project, much less being able to break things down into components.
Other disciplines have very component-driven architectures with reasonably tight interfaces to allow parallel development. Software engineering still allows too much bleed through in the corresponding areas.
There are a lot of software applications out there, but many of them have suffered dramatically in some aspect or the other and would not come close to being called successful. There is a small body of successful, similar projects.
Also, there is also a lack of a large body of designers and builders who have worked on several similar and successful projects. Related to the successful project issue, not having the talent who has been there and done that, makes things very difficult from a repeatability point of view.
Software projects generally suffer from bad estimation. Since the repeatability factor is so low, it is difficult to project how large it will end up being and how long something will take to build.
Quality assurance and quality control are not emphasized as heavily as it could or should be for projects. This corroborates to having looser interfaces between components, and not having rigid specifications for how components should work. That looseness allows for unintended consequences and for mistakes to happen.
There is a lack of consistently measurable qualifications. Generally, software engineers speak of the number of years they have worked in a certain language or technology. They use time as a substitute for caliber or quality of skill.
Finally, software engineering has made significant strides. Organizations are working to standardize on baseline knowledge for software engineers. There is room for improvement, but the software engineering has come a long way in a short period.