Seminário 2 - Engenharia de Software I
Por: matheusdpb • 4/9/2018 • Artigo • 2.367 Palavras (10 Páginas) • 215 Visualizações
Seminário 2 – Engenharia de Software I
Abstract. In this article we will analyze the various problems related to software engineering present in a real company, in order to understand them and correct them, using the different concepts and methodologies studied in class, as well as explain in more detail how each concept works, as well as its advantages over the lack of software engineering in any company.
Resumo. Nesse artigo iremos analisar os diversos problemas referentes a engenharia de software presentes em alguma empresa real, afim de procurar entende-los e corrigi-los, utilizando os diversos conceitos e metodologias estudados em aula, assim como explicar de forma mais detalhada como funciona cada conceito, assim como suas vantagens em relação a falta da engenharia de software em alguma empresa.
1. Introdução
Esse artigo tem como objetivo realizar uma pesquisa de um cenário real de alguma empresa cuja a engenharia de software não é aplicada, ou aplicada, mas de forma não correta e eficiente. Buscando assim, conhecer como funciona a empresa, analisar seus problemas, e com a ajuda dos conceitos e metodologias vistos na disciplina de Engenharia de Software, sugerir soluções que resultariam numa otimização dos processos da empresa, agregando maior valor de trabalho e desenvoltura na entrega dos seus serviços.
Inicialmente será comentado mais sobre a empresa, sua área de atuação e seus serviços, após serão analisados os problemas que essa empresa de desenvolvimento de software tem desde a parte de gerenciamento, requisitos, processos até a parte dos testes. Após, será explorado os principais motivos desses problemas e suas devidas soluções com base no que foi visto em aula. E por fim, será mostrado como a engenharia de software se adequa as empresas e como ajuda na resolução das demandas do cotidiano.
2. Empresa
Esse artigo foi realizado com base em uma empresa em que trabalhei ano passado, cujo seu principal objetivo era prestar auxílio as empresas nos processos de gestão de projetos, assim como a disponibilização de soluções para suportar toda esta metodologia.
É uma empresa parceira da Microsoft, especializada em soluções para gerenciamentos de projetos, investimentos e portais, que utiliza de ferramentas como SharePoint, MS Project, Power BI e Reporting Services, sendo os dois primeiros para oferecer uma melhor maneira de gerencia para seus clientes, e o restante para a criação de relatórios.
O principal produto é a implantação do PPM, nessa implantação há três principais fases, que são, parametrização, treinamentos, homologação.
O PPM é a ferramenta onde se gerenciam os projetos, o andamento e a finalização. No SharePoint é criado um fluxo de trabalho para os projetos da empresa, para cada cliente é feito um fluxo conforme sua necessidade. Pois em projetos, há diversas fases, que são controladas por este fluxo, diversas aprovações e uma fase de portfólio, onde é possível comparar os projetos e decidir quais serão implementados. A comparação pode ser feita por qual será mais lucrativo, melhor para o meio ambiente, etc.
A empresa era pequena internamente, sua equipe de TI conta com um Gerente de Serviços, um Gerente de Projetos e 6 analistas/desenvolvedores. Acredito que ainda se trabalha com metodologia tradicional para entregar seu produto aos seus clientes, ou seja, elaborando um cronograma no início de cada projeto, onde eram listadas as tarefas com a quantidade de horas que devem ser cumpridas e o dia das estregas, porém, é somente ao final do projeto concluído que era feita a homologação com o cliente.
As soluções são usadas por mais de 15 mil usuários (2014). Fornece suporte com atendimento em mais de 23 países. Alguns clientes da empresa: CMPC, Embraco, Votorantim, Yara, GKN Driveline, Gerdau, Indigo, Grendene, Getnet, Grupo RBS, Zaffari Bourbon, Stihl, entre outros.
3. Problemas
Após uma análise referente a organização da empresa, e os métodos utilizados, foi possível encontrar alguns problemas com um enorme déficit referente a engenharia de software, que acabam por afetar e impedir que a empresa tenha um maior aproveitamento dos seus serviços e funcionários, podendo ser corrigidos com alguns dos diversos métodos apresentados em aula.
3.1. Má organização das tarefas e a falta de testes.
Um dos problemas que mais afetavam o aproveitamento dos funcionários é a respeito da divisão de tarefas proposta durante a gestão do projeto. A cada projeto era desenvolvido um cronograma proposto pelo Gerente de Serviços, contendo todas as tarefas necessárias para a realização do mesmo, assim como qual funcionário será responsável pelo desenvolvimento de cada tarefa.
Visto que as tarefas por sua vez, tem complexidades diferentes, ou seja, algumas serão mais fáceis de realizar do que outras. O que ocorria na maioria das vezes era encontrar funcionários parados no meio do projeto por já ter concluído suas respectivas tarefas definidas no cronograma, mesmo quando algum outro funcionário pode estar sobrecarregado, podendo gerar até mesmo um atraso na entrega do serviço.
Isso ocorria porque somente o Gerente de Serviços é o responsável por definir outra tarefa a ser feita, privando assim, qualquer autonomia que o funcionário poderia ter para definir suas próprias tarefas, desperdiçando um enorme tempo em que poderia ser aproveitado para agilizar os procedimentos e otimizar o andamento de uma entrega.
Outro caso relacionado a gestão é em relação aos testes, visto que a empresa não continha de fato um testador, o que por sua vez, ficava nas mãos do próprio desenvolvedor a realizá-los. Algo que como foi comentado em aula, é impossível ter uma eficiência satisfatória sendo que o mesmo que testa, foi o responsável pelo desenvolvimento, resultando diversas vezes em testes superficiais, gerados muitas vezes por questões de orgulho e confiança de que seu código está sempre correto.
3.2. Falta de organização da documentação dos requisitos
O segundo problema e referente a parte documentação de requisitos, onde era escrito em um documento onde especificamos como será o projeto, que alem dos requisitos, era documentado todos os campos que deveriam ser customizados, assim de como seria o fluxo de trabalho, os relatórios,
...