Olá Pessoal!
Neste artigo vamos apresentar um histórico de fundamentos da Engenharia de Software para entender sua relevância, analisando algumas questões e entender como esse assunto costuma ser cobrado pelas bancas.
Segundo [Pressman 2016], à Engenharia de Software abrange um processo, um conjunto de métodos (práticas) e ferramentas que possibilitam aos profissionais desenvolverem software de altíssima qualidade, conforme demonstrado na Figura 1.
Figura 1 – Camadas da Engenharia de Software [Pressman 2016]
[Pressman 2016] define a qualidade, como item preponderante para o sucesso de um software, e vários estudos determinam que ela esteja intrinsicamente ligada ao atendimento à requisitos. A camada de processo constitui o pilar para o controle e gerenciamento do trabalho de desenvolvimento. A camada de métodos oferece subsídios técnicos para as tarefas desenvolvidas durante o ciclo de desenvolvimento, e por último na camada mais alta temos as ferramentas fornecendo automação das atividades de forma organizada e repetível.
A disciplina de Engenharia de Software define esses elementos como fundamentais para o sucesso do projeto de software. Em meados dos anos 70, surgiram os primeiros elementos dessa área, devido ao evento chamado “crise do software”: onde ocorria que os computadores evoluíam cada vez mais rápido com a introdução dos microchips e os softwares não estavam acompanhando no mesmo ritmo essa evolução.
[Sommerville 2011] relata os maiores problemas enfrentados a época:
- Estouro de orçamento;
- Prazos não cumpridos;
- Software que não atendem aos requisitos do usuário;
- Projetos com poucos elementos para permitir sua gestão e código fonte de difícil manutenção.
No próximo tópico faremos um apanhando do histórico dos processos de software e como esses problemas têm sido tratados, fundamentados nas camadas apresentadas na Figura 1.
Inicialmente, será apresentado o histórico dos processos de software com os principais modelos de desenvolvimento de software.
Histórico dos processos de Software
O primeiro processo de software é chamado de “waterfall” ou cascata, baseado no processo de fábrica de automação onde as atividades são feitas em sequência partindo de tarefas planejadas e repetidas. O termo surgiu do artigo publicado em 1970 por W.W Royce. Esse processo é dividido em fases conforme Figura 2. Cada fase é feita sequencialmente sendo necessária a conclusão da fase predecessora.
Figura 2 – Processo em Cascata “Waterfall” [Gomes 2013]
Alguns problemas comuns nesse modelo referem-se à forma engessada das atividades executadas, por exemplo, mudanças de requisitos que são comuns em projeto de software não ocorrem após a sua fase específica e a falta de interação com os clientes e usuários nas atividades de desenvolvimento ou codificação.
Esse processo trouxe algumas vantagens à época, pois foi um grande avanço estruturar atividades de forma organizada. Antes do seu surgimento isso não ocorria o que tornava o insucesso dos projetos de softwares uma dificuldade comum [Sommerville 2011].
Modelo Iterativo e Incremental
[Pressman 2016] define o modelo iterativo de desenvolvimento em ciclos, onde os riscos são tratados e melhor gerenciados. Os pequenos itens do software a serem desenvolvidos são feitos em pequenos espaços de tempo.
Esse modelo trouxe novas perspectivas de trabalho e foi uma evolução em comparação ao processo cascata. A constante comunicação com os usuários trouxe a desvantagem de inúmeras mudanças de requisitos e escopo, fato que não ocorria no modelo cascata que fechava uma fase específica para o levantamento de requisitos e após a conclusão de uma fase nada era modificado até o fim de todo o processo. Na Figura 3 está à representação do modelo Iterativo.
Figura 3 – Fluxo de Processo Iterativo [Pressman 2016]
Já po modelo incremental introduziu a noção de entregas. O fluxo de trabalho definido pressupõe o planejamento das atividades em paralelo e integradas após sua conclusão. Este modelo combina elementos do modelo cascata de maneira iterative. O núcleo do produto (software) é desenvolvido na entrega 1 e a cada novo ciclo um novo incremento de funcionalidades, a Figura 4 explicita esse processo.
Figura 4 – Modelo Incremental [Pressman 2016]
Processo Unificado
No livro que deu origem ao Processo Unificado (UP), Jacobson, Booch e Rumbaugh (1999) discutem a necessidade de um processo de software “dirigido a casos de uso, centrado na arquitetura, iterativo e incremental”. O objetivo inicial com o processo unificado foi aproveitar o melhor dos modelos de software descritos anteriormente.
Figura.5 – Processo Unificado [Pressman 2016]
Na fase de concepção são executadas as atividades de comunicação com o cliente e de planejamento, uma arquitetura de software inicial é esboçada para o sistema, são identificados requisitos de negócio para atendimento as necessidades dos clientes e/ou usuários, recursos, avaliados riscos, definido prazos, tudo de forma preliminar com base no escopo definido.
A fase de elaboração detalha os itens elencados na primeira fase com maior riqueza de detalhes e o replanejamento é feito nesse momento para atender o escopo, prazos e riscos.
Já na fase de construção ocorrem as etapas de maneira similar aos processos tradicionais, adotados pelo UP de forma iterativa e incremental, Por fim na fase de transição a entrega e realimentação (feedback).
Um processo conhecido que é baseado no UP é o Rational Unified Process (RUP), criada pela empresa Rational que foi comprada pela IBM. Uma das desvantagens do UP foi o excesso de documentação gerada em cada fase. Em muitos casos ocorrem o excesso de retrabalho para atualização e modificação da documentação gerada.
Pois é pessoal de forma bem resumida sintetizamos aqui os processos classícos da Engenharia de Software, não entrando nas tão faladas metodologias ágeis, já tratadas em outros artigos no nosso blog. Agora vamos analisar duas questões sobre o tema.
Ano: 2019 Banca: CESPE / CEBRASPE Órgão: SLU-DF Prova: CESPE – 2019 – SLU-DF – Analista de Gestão de Resíduos Sólidos – Informática
Acerca de conceitos e disciplinas da engenharia de software, julgue o item que se segue.
No modelo de desenvolvimento de software em cascata, a abordagem é orientada ao risco e as tarefas são organizadas nos seguintes ciclos: determinar objetivos, identificar e resolver riscos, desenvolver e testar, e planejar a próxima iteração.
Certo
Errado
Ano: 2018 Banca: CESPE / CEBRASPE Órgão: IPHAN Prova: CESPE – 2018 – IPHAN – Analista I – Área 7
Com relação à engenharia de software, julgue o seguinte item.
No modelo em cascata, com exceção do sequenciamento dos estágios de requisitos e de análise, os demais são executados em paralelo, iniciando-se antes do término do estágio seguinte.
Certo
Errado
O gabarito pode ser consultado no final desse artigo.
Para Pensar !!!
Um dos problemas para os concurseiros nesse tema é a quantidade de processos existentes devido a classificação dos autores clássicos como PRESSMAN e SOMMERVILLE. Não pense que nesse post tratamos de todos !!! Apenas citamos os mais utlizados na prática e os mais cobrados pelas bancas em geral ! No Gran Cursos Online temos diversas aulas para explicar quando se deve dar atenção a cada um dos processos e classificações, pois as diversas bancas examinadoras cobram esse assunto de diversas maneiras.
Dessa forma encerro esse artigo com essa breve introdução sobre o assunto !
Até mais !
GABARITO
- O modelo iterativo que tem foco na gestão dos riscos, por isso diminui os ciclos entre as atividades para ter feedback constante, já que o maior problema em custo de software está na correção de requisitos problemáticos, a descoberta desse problema em fases avançadas do desenvolvimento tem um custo altíssimo. Esse também é um dos problemas do modelo cascata.
- O modelo cascata incorpora até mesmo uma certa interação entre as fases como visto na Figura 2, mas não prevê atividades executadas em paralelo, o software só será entregue no final da sequência de etapas.
Referências
[1] Souza, A. R. R., Monteiro, L. A., & Almeida, W. H. C. Gerenciamento de Projetos Ágil na prática: Processos e Ferramentas para Apoio a Gestão. ERIPI 2017.
[2] PRESSMAN, R. S. Software engineering : a practitioner’s approach (9ª ed.). New York: Higher Education, 2016.
[3] SOMMERVILLE, I. Software Engineering (Vol. 9). Pearson, 2011.
Professor MSC, Washington Almeida
Doutorando e mestre em Engenharia de Software pelo Centro de Estudos e Sistemas Avançados do Recife – C.E.S.A.R. Atualmente é Analista Judiciário na Justiça Federal (TRF1), Professor no Gran Cursos Online e na Universidade de Brasília – UNB.
Gostei do seu artigo!
Obrigado !!!