Buscar

02_Artigo

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 9 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 9 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 9 páginas

Prévia do material em texto

Modelos de Processos de Engenharia de Software 
Rafael Orivaldo Lessa, Edson Orivaldo lessa Junior 
Princípios da Engenharia de Software – Universidade do Sul de Santa Catarina 
(UNISUL) 
Caixa Postal 88132-000 – Palhoça – SC – Brasil 
edsonlessajunior@yahoo.com.br, rafinha_lessa@yahoo.com.br 
Abstract. The software engineering appeared to correct problems with regard 
to the development of software projects, from this sprouting models of 
processes and guide of developments had been created for improve of the 
process of development of software. The article will show to some models of 
processes and a guide calling SWEBOK, that was created by members of the 
which had scientific community to the vast material that involves the software 
engineering. 
Resumo. A engenharia de software surgiu para corrigir problemas com 
relação ao desenvolvimento de projetos de software, a partir desse surgimento 
modelos de processos e guia de desenvolvimentos foram criados para 
otimização do processo de desenvolvimento do software. O artigo mostrará 
alguns modelos de processos e um guia chamando de SWEBOK, que foi 
criado por membros da comunidade cientifica devido ao vasto material que 
envolve a área. 
1. Engenharia de Software 
O software de computadores é hoje uma tecnologia importante no âmbito mundial, 
tendo um crescimento rápido desde a década de 1950, com esse ríspido crescimento 
começou a ocorrer problemas relacionados a correções, adaptações, aperfeiçoamento é 
ainda o processo de manutenção que consome mais recurso e mais pessoas que na 
criação de novos software. Com todos esses problemas novos conceitos começaram ser 
criados com o da Engenharia de Software. 
A Engenharia de software segundo Fritz Bauer “é a criação e a utilização de sólidos 
princípios de engenharia a fim de obter softwares econômicos que sejam confiáveis e 
que trabalhem eficientemente em maquinas reais”. Já IEEE desenvolveu uma definição 
mais abrangente que é “(1) aplicação de uma abordagem sistemática, disciplinada e 
quantificável, para desenvolvimento, operação e manutenção do software, isto é a 
aplicação da engenharia ao software. (2) Os estudos de abordagens como as de (1)”. 
(PRESSMAN, 2006) 
Todas essas definições estão inseridas no livro de Pressman que ressalva que a 
engenharia de software é uma tecnologia em camadas (Ferramentas, Métodos, Processo, 
Foco na qualidade) e a organização devem se apoiar num compromisso de qualidade. 
 
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
 
2. Técnicas de engenharia de Software 
 
A Engenharia de Software é uma técnica de sucesso para projetos de software, pôr em 
sua maioria, não são aplicadas na produção de Software. No entanto, ainda há 
problemas em produzir software complexo, que atenda às expectativas dos usuários e 
que seja entregue dentro do prazo e do orçamento estabelecido. Muitos projetos de 
software ainda têm problemas, e isso levou alguns críticos, como Pressman 
(PRESSMAN, 2006), a sugerirem que a Engenharia de Software está em um estado de 
aflição crônica. 
À medida que a nossa capacidade de produzir software aumentou, também cresceu a 
complexidade dos sistemas requeridos. Novas tecnologias que resultam da convergência 
de sistema de computadores e de comunicação, trazem novas questões para os 
engenheiros de software. Por essa razão e pelo fato de muitas empresas não aplicarem 
as técnicas de Engenharia de Software de maneira eficaz, apresenta diversos problemas. 
A situação não é tão ruim como os pessimistas sugerem, mas, com certeza, há espaço 
para melhorias. 
Um modelo de processo de software é uma representação abstrata de um processo de 
software. Cada modelo de processo representa um processo a partir de uma perspectiva 
particular, de uma maneira que proporciona apenas informações parciais sobre o 
processo (SOMMERVILLE 1995). Abaixo constam alguns modelos de processos de 
softwares que serão abordados no artigo: 
• O modelo em cascata; 
• Desenvolvimento evolucionário; 
• Desenvolvimento iterativo 
o Modelo de desenvolvimento espiral; 
o Modelo de desenvolvimento incremental. 
• Desenvolvimento baseado em componentes 
Existem outros modelos além dos citados acima, que Pressman (2006) coloca em seu 
livro, mas o artigo não entrará em detalhes nesses modelos ele são: 
• Modelo Incremental; 
• Modelo RAD; 
• Modelo de Desenvolvimento Concorrente; 
• Modelo de Métodos Formais; 
• Processo Unificado. 
2.1 Cascata, Linear ou Clássico 
 
O modelo cascata descreve um método de desenvolvimento que é linear e seqüencial. 
Na primeira vez que uma fase de desenvolvimento é completada, o desenvolvimento 
prossegue para a próxima fase e não há retorno. A vantagem do desenvolvimento 
 
cascata é que ele permite controle departamental e gerencial. Um planejamento pode ser 
atribuído com prazo final para cada estágio de desenvolvimento e um produto pode 
prosseguir no processo de desenvolvimento, teoricamente ser entregue no prazo. O 
desenvolvimento move do conceito, através do projeto (design), implementação, teste, 
instalação, descoberta de defeitos e termina com a operação e manutenção. Cada fase de 
desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposição ou 
passos iterativos. (PRESSMAN, 2006) 
A desvantagem do desenvolvimento em cascata é que ele não permite muita 
flexibilidade ou revisão. A primeira vez que uma aplicação está em estágio de teste é 
muito difícil retornar e mudar alguma coisa que não foi bem pensada no estágio 
conceitual. 
 O modelo cascata inicia de uma abordagem orientada a projetos para a engenharia de 
software. O projeto é considerado uma tarefa claramente delineada para a qual os 
resultados desejados podem ser determinados completamente e sem ambigüidade. 
Pressman (1995) aponta alguns problemas identificados neste ciclo de vida: 
• Os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe. 
Alguma iteração sempre ocorre e traz problemas na aplicação do paradigma 
• Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. 
O ciclo de vida clássico exige isso e tem dificuldade de acomodar a incerteza 
natural que existe no começo de muitos projetos 
• O cliente deve ter paciência. Uma versão de trabalho dos programas não estará 
disponível até um ponto tardio do cronograma do projeto. Um erro crasso, se 
não for detectado até que o programa de trabalho seja revisto, pode ser 
desastroso. Peters (2001) aponta vantagens e desvantagens: 
Vantagens: Permitir a gerência do baseline, que identifica um conjunto fixo de 
documentos produzidos como resultado de cada fase do ciclo de vida. 
Desvantagens: não é capaz de estabelecer como efetuar engenharia reversa de um 
sistema existente e faltam noções de prototipação rápida e desenvolvimento 
incremental. 
 
 
 
Figura 1. Modelo de processo em Cascata 
 
2.2 Prototipação 
Prototipação, é a montagem de protótipos, ela pode ser classificada de acordo com uma 
variedade de dimensões. A abordagem de prototipação tem um número de vantagens 
importante a oferecer, das quais nós indicamos a mais importante delas aqui. Primeira 
todo o requisitos de sistema não tem que ser completamente determinado 
antecipadamente e pode mesmo ser trocada durante o curso do projeto. Segundo, a 
entrega de prototipação clara, definições de sistema entendível e especificações para o 
usuário final. Como conseqüência, o envolvimento e satisfação do usuário final são 
fortemente aumentados. Finalmente, prototipação faz isso possível para rapidamente 
testar o ambiente de desenvolvimento voltado para a funcionalidade, performance, 
interface com banco de dados, etc. (IBM, 2002). 
Porém algumas desvantagens podem ser apontadas como, por exemplo, a modelagem é 
iniciada antecipadamente, sem ter uma atenção devotada suficientemente para a analise 
de uma situação corrente e desejada, reconhecimento do problema e formulação do 
problema que são pelo menos tão importantescomo a própria solução. Especialmente 
na prototipação evolucionária o perigo da falha do projeto existe: toda iteração ajusta o 
protótipo de uma forma que menos da funcionalidade desejada ou funcionalidade 
supérflua é incorporada dentro do protótipo (IBM, 2002). Um perigo final é que a 
prototipação pode lidar com entusiasmo do usuário final. O processo de prototipação 
pode dar ao usuário final a impressão que praticamente qualquer sugestão pode ser 
implementada, não importa qual estágio do processo de desenvolvimento se está. Além 
disso, para os usuários não está claro o porquê da demora para entregar a aplicação final 
depois que uma versão demo do sistema foi exibida. 
 
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
 
 
Figura 2. Modelo de processo de Prototipação 
 
2.3 Modelo de Processo de Software Evolucionário 
 
Estudos mostraram que o software, como todos os sistemas complexos, evoluem 
durante um período de tempo e os requisitos do negócio e do produto mudam 
frequentemente a medida que o desenvolvimento prossegue dificultando um caminho 
direto para um produto final (PRESSMAN, 2006). 
Os modelos que serão citados à frente são interativos e caracterizam-se pela forma 
como se desenvolve versões cada vez mais completas do software. 
2.3.1 Espiral 
O modelo espiral foi desenvolvido para abranger as melhores características tanto do 
ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo 
elemento, a análise de riscos que falta a esses paradigmas. O modelo define quatro 
importantes atividades representadas por quatro quadrantes: 
1. Planejamento: determinação dos objetivos, alternativas e restrições. 
2. Análise de riscos: análise de alternativas e identificação/resolução de riscos. 
3. Engenharia: desenvolvimento do produto no “nível seguinte”. 
4. Atualização feita pelo cliente: avaliação dos resultados da engenharia. 
Ele usa uma abordagem “evolucionária” à engenharia de software, capacitando o 
desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O 
modelo espiral usa a prototipação como um mecanismo de redução de riscos, mas, o 
que é mais importante, possibilita que o desenvolvedor aplique a abordagem de 
prototipação em qualquer etapa da evolução do produto. Ele mantém a abordagem de 
passos sistemáticos sugerida pelo ciclo de vida clássico, mas incorpora-a numa estrutura 
iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma 
consideração direta dos riscos técnicos em todas as etapas do projeto e, se 
Neutel
Highlight
Neutel
Highlight
Neutel
Highlight
 
adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemáticos 
(Pressman, 2006). 
O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as 
características positivas da gerência (documento associado às fases do ciclo) do modelo 
de cascata com as fases sobrepostas encontradas no modelo incremental e, também, 
com as versões anteriores de um sistema do modelo de prototipação. O modelo em 
espiral parte do princípio de que a forma do desenvolvimento de software não pode ser 
completamente determinada de antemão. (Pressman, 2006). 
A prototipação é vista como um meio de redução de riscos, a permitir que se descubram 
os problemas potenciais antes de se comprometer com um sistema completo. O modelo 
caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em 
espiral possui quatro atividades principais: 
• Elaborar objetivos, restrições e alternativas para entidades de software. 
• Avaliar alternativas com relação aos objetivos e restrições, e identificar as principais 
fontes de riscos. 
• Elaborar a definição das entidades de software em um projeto. 
• Planejar o próximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco. 
 
 
Figura 3. Modelo de processo em Espiral 
 
2.3.2 Incremental 
O modelo incremental segundo Pressman (2006) combina elementos do modelo cascata 
sendo aplicado de maneira interativa. O modelo de processo incremental é interativo 
igual à prototipagem, mais diferente a prototipagem o incremental tem como objetivo 
apresentar um produto operacional a cada incremento realizado. 
Esse modelo é muito útil quando a empresa não possui mão de obra disponível no 
momento para uma implementação completa, dentro do prazo estipulado. 
Neutel
Highlight
 
 
Figura 4. Modelo de processo Incremental 
 
2.3.3 Desenvolvimento baseado em componentes 
Desenvolvimento baseado em componentes ou component-based development (CBD) 
também é conhecido como component-based software engineering (CBSE) ou 
simplesmente componente de software (BROWN, 1997). 
Pressman (2006) não define o que é um componente e restringe-se a dizer que o modelo 
de desenvolvimento baseado em componentes utiliza paradigma de orientação a objetos 
baseando-se em uma classe como código reutilizável, ou seja, o componente. 
Em orientação a objetos uma classe encapsula dados e algoritmos e este último também 
pode ser usado para manipular os dados. 
Pressman (2006) caracteriza esse modelo como incorporador do modelo espiral com 
uma abordagem iterativa para a criação de software. Através desta abordagem uma 
biblioteca de classes é construída com as classes identificadas no desenvolvimento do 
software e a partir de então toda iteração da espiral deverá verificar o conteúdo da 
biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas 
na biblioteca para posterior reuso. 
 
3 SWEBOK 
Engenharia de software possui vasto material e várias técnicas para sucesso de software, 
então o IEEE montou um comitê que se reuniram e montaram um guia chamado 
SWEBOK que desmembra a engenharia de software em dez áreas de conhecimento que 
são: 
• Requisitos de Software 
• Projeto (Design) de Software 
 
• Construçã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 
Cada uma das áreas de conhecimento é decomposta em itens, que são os assuntos de 
conhecimentos a serem considerados pelo projeto. Conforme o projeto deixa claro, os 
engenheiros de software não devem receber somente os conhecimentos estabelecidos 
pelas respectivas áreas, mas também outros conhecimentos dos cursos com os quais a 
Engenharia de Software se relaciona. Foi montado sobre três versões onde a ultima 
definiu-se como final. São elas: 
• Homem de palha 
• Homem de pedra (1998-2001) 
• Homem de ferro (2003) 
Por a engenharia de software ser uma área muito abrangente o SWEBOK não consegue 
abranger todas as áreas de conhecimento. Um problema que o guia enfrenta é que a 
engenharia de software continua mudando continuamente inspirada em novas 
tecnologias e praticas, tornando o guia muitas vezes defasado. 
O SWEBOK ainda correlaciona áreas que ele não considera que estejam dentro do 
escopo da engenharia de software, e sim disciplinas de apoio que são: 
• Engenharia da computação; 
• Ciência da computação; 
• Gerenciamento; 
• Matemática; 
• Gerência de projetos; 
• Gerenciamento da qualidade; 
• Ergonomia de software; 
• Engenharia de sistemas. 
 
Mesmo com algumas limitações o SWEBOK é um ótimo guia que apóia o 
desenvolvimento de software, é que pode ser usado como um diferencial e apoio nesse 
desenvolvimento. (SWEBOK, 2004) 
4 Conclusão 
A Engenharia de Software é um processo importante no desenvolvimento de Software, 
mesmo não possuindo uma forma especifica para realização de processos todos os 
fatores pode funcionar em cada empresa tem que optar pela melhor técnica de 
desenvolvimento, a melhor opção e mesclarem as técnicas. 
O SWEBOK é uma das melhores opções, pois se trata de um guia que foi constituído 
por vários pesquisadores, portanto é um material completo, porem inacabado,já que 
novas técnicas continuam surgindo, mas contem as principais funções de 
desenvolvimento. 
Pode-se salientar que a Engenharia de software é um critico fator de sucesso da 
empresas de desenvolvimento de software, esses conceitos são organizados e agregam 
viabilidade de produção de software com qualidade, prazo e custos. 
Referências Bibliográficas 
BROWN, ALAN W., On Components and Objects: The Fundation of Component-
Based Development, Assessment of Software Tools and Tecnology, Procedings Fifth 
International Symposium on Proceedings - IEEE, 1997. 
IBM; Practicing Object-Oriented Analysis and Design- ERC2.2.; IBM Education and 
Training; 2002L. 
PRESSMAN, ROGER S., Engenharia de Software- (3ª edição), São Paulo, Ed. Makron 
Books, 1995. 
PRESSMAN, ROGER S., Engenharia de Software- (6ª edição), São Paulo, Ed. 
McGrawHill, 2006. 
PETERS, JAMES F., Engenharia de Software: Teoria e Prática, Rio de Janeiro, 
Editora Campus, 2001. 
SOMMERVILLE, I. Software Engineering (International Computer Science Series). 5a 
Edição. Reading: Addison-Wesley, 1995. 
SWEBOK 2004, Guide for the Software Engineering Body of Knowledge, 2004 
version, IEEE Computer Society, California, EUA.

Outros materiais