Site Campus - Engenharia de Software - Sistemas mais seguros e rápidos

Engenharia de Software – Sistemas mais seguros e rápidos

Engenharia de Software - Sistemas mais seguros e rápidosTrabalhar com Engenharia de Software é ter certeza de estar utilizando um sistema mais ágil, seguro e bem construído.

Engenharia de software é uma área do conhecimento da informática voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de ciência da computação, gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.

O surgimento da engenharia de software está ligado à tentativa de se contornar diversos problemas enfrentados nos anos 60 na área de desenvolvimento de sistemas. O termo engenharia não é mero adereço, pois oferecer um tratamento sistemático e controlado é um dos objetivos desta área de conhecimento.

Black Week Site Campus

As bases científicas da engenharia de software incluem o uso de modelos abstratos e precisos que podem ser utilizados pelo engenheiro para especificar, projetar, implementar e manter sistemas de software. Além disso, o processo de desenvolvimento de software também é orientado e planejado através da engenharia de software.

As áreas de conhecimento da Engenharia de Software são as seguintes:

• Requisitos de Software
• Projeto (Design) de Software
• Implementação de Software
• Teste de Software
• Manutenção de software
• Gerência de Configuração de Software
• Gerência de Engenharia de Software
• Processos de Engenharia de Software
• Ferramentas e Métodos de Engenharia de Software
• Qualidade de Software

Processos de Desenvolvimento de Software

Processo de software, ou processo de engenharia de software, é uma seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação, projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.

Através de modelos de processos de software é possível representar o processo de gerenciamento do desenvolvimento do produto. Existem discussões no meio acadêmico quanto à definição do termo metodologia. Serão apresentados a seguir os modelos de ciclo de vida de desenvolvimento de software mais conhecidos.

Modelo em Cascata

Provavelmente o modelo mais conhecido de ciclo de vida de desenvolvimento, surgiu na década de 1970 e é utilizado até os dias de hoje em sua forma pura e em outras como a iterativa, por exemplo. Este modelo está presente na base de diversas metodologias. Até seu surgimento, não havia consenso de como se desenvolver software na indústria.

A proposta do modelo Cascata Puro consiste na execução das atividades de desenvolvimento de software em uma seqüência ordenada. Desta forma, a passagem para determinada atividade exige como critério a finalização da atividade imediatamente anterior. As principais atividades do modelo são: requisitos de sistema, requisitos de software, análise, projeto de programa, codificação, teste e operação.

O ciclo de vida em cascata é linear. Os nomes de cada etapa podem variar, entretanto, a evolução de uma fase para outra acontece com o término da fase anterior. É comum que as etapas sejam ordenadas a partir da análise de requisitos, passando em seguida para a fase de desenho, codificação, implementação, teste e por fim a manutenção do sistema.

Neste modelo, apenas a fase final entrega o produto. Sendo assim, o tempo para que o software comece a dar retorno para o cliente é muito grande. Além disso, o custo de alterações e correções no sistema são altíssimos.

Ainda assim, é um modelo que funciona muito bem com equipes júnior, sem muita experiência, pois possui ampla documentação e detalhamento dos requisitos. A interação entre programadores e cliente é mínima, o que pode ser um fator positivo ou negativo dependendo da perspectiva. A falta de contato permite menos coragem, pois permite ao programador cometer equívocos ou ser negligente. Por outro lado, permite que o trabalho flua de maneira linear e aumenta a previsibilidade do projeto.

Embora este modelo já tenha sofrido inúmeras revisões, seu modelo original não prevê iterações. Uma vez tendo sido aplicado em larga escala, ficou comprovado que o modelo precisaria de mais feedback por parte do cliente durante o desenvolvimento. Negócios mudam, por isso a inflexibilidade do sistema precisaria ser quebrada. De qualquer modo, a idéia de iteração não foi incorporada a filosofia do modelo inicial.

A ênfase dada pelo modelo em cascata na documentação vai além de mero texto, inclui gráficos e até mesmo simulações. Comumente adotado quando existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade, a duração do projeto é pequena, isto é, menor do que dois anos e o sistema completo deve estar disponível de um única vez.

Modelo Espiral

O modelo espiral foi proposto por Barry Boehm em 1988. Ele reúne características dos modelos cascata e prototipação, sendo acrescido ainda à análise de riscos. A cada volta na espiral, começando de dentro para fora, é uma nova fase no processo de desenvolvimento.

O processo é evolutivo e o trabalho é dividido entre 6 regiões, que são: comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e evolução e, avaliação do cliente. O número de tarefas por regiões pode variar conforme o tamanho e complexidade do projeto.

Para qualquer metodologia sempre existirão uma série de vantagens e desvantagens. No caso do modelo em espiral não é diferente. Em tese, quanto mais recursos forem destinados ao desenvolvimento, maior serão as interações na espiral e, desta forma, menor serão os riscos sobre o projeto. Diferente do método em cascata, o modelo em espiral trabalha com interações. Ao fim de cada fase existem atividades de verificação, que garantem maior satisfação do cliente e maior controle gerencial sobre a atividade.

Conclusão

Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, mas em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de software saltam a vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativa permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada interação à volta da espiral pode ser baseada num modelo diferente e pode ter diferentes atividades.

No caso da espiral, não foi a necessidade do envolvimento dos utilizadores que inspirou a introdução de interação, mas sim a necessidade de identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades são repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. Se forem encontrados problemas numa versão inicial do documento, reentra-se nas fases de levantamento, análise, documentação e validação. Isto repete-se até que seja produzido um documento aceitável ou até que fatores externos, tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos.

Clique aqui e veja uma aula sobre Gerenciamento de Serviços e Tecnologia da informação com ITIL do nosso curso livre LEAP – Gestão de Startups – faça esta aula gratuitamente e aprenda mais!


#
Compartilhe!
Fale com o Site Campus

Tags: , , , ,