FATEC -SP

Trabalho de Engenharia de Software

Vitor Itiro Oki Takahashi

20118921

São Paulo -SP

2020
Sumário
Introdução...................................................................................................................................3
Resumo do artigo de Barry Boehm “A Spiral Model of Software Development and
Enhancement (1988)”...............................................................................................................4
Modelo Espiral...........................................................................................................................5
Processo Unificado...................................................................................................................8
Norma NBR 12207....................................................................................................................9
Considerações finais...............................................................................................................10
Referências..............................................................................................................................11
Introdução

Este trabalho demonstra a evolução do processo de desenvolvimento de

software com base no artigo "“A Spiral Model of Software Development and
Enhancement" de Barry W. Boehm. De acordo com o artigo, é possível analisar
e discutir a transição e evolução nos processos de desenvolvimento,
observando que se trata de ajustes ao modelo em cascata de grande escala e
que ferramentas de outros métodos foram adicionadas e análises de risco
realizadas. Finalmente, outros métodos são brevemente mencionados, como
Modelos espirais, processo baseado em componentes, desenvolvimento
concorrente, processo unificado e norma NBR 12207.
Resumo do artigo de Barry Boehm “A Spiral Model of
Software Development and Enhancement (1988)”

O Artigo trata-se de instruir os desenvolvedores sobre o processo de

desenvolvimento de software em cascata. Desta maneira mostrando como usar
de maneira útil e eficaz, dando exemplos reais e fluxogramas para comparar. O
foco principal é o gerenciamento e inspeção de código. Mostrando que o
processo de inspeção do código feito de maneira correta pode trazer mudanças
significativas e melhorando a qualidade na entrega
De acordo com o artigo, o desenvolvimento de desenvolvimento de
software também é estudado, portanto, pode-se dizer que o modelo em
cascata (Waterfall) é o primeiro modelo desenvolvido com foco no
desenvolvimento e entrega do programa com o menor número de erros
participando de todos os requisitos do cliente e preparação adequada
documentação para usuários. O segundo modelo é evolutivo, que consiste em
etapas com aumento do produto de software funcional, a gestão determina a
experiência funcional, mas sua principal falha é o aprimoramento dos códigos
antes do aprimoramento estrutural do software. O terceiro modelo é o modelo
de transformação, cuja principal característica é o reconhecimento da
capacidade de converter automaticamente a especificação formal do produto
de software em um programa que satisfaça as especificações, usando iteração,
prototipagem e mudanças com base no feedback do cliente, mas é um grande
problema estrutural. e as otimizações acabam sendo repetitivas.
Modelo Espiral

O modelo espiral é um processo de programação evolucionário

amplamente utilizado hoje que segue o mecanismo de iteração em cascata do
protótipo e segue os aspectos sistêmicos e de controle do modelo em cascata
em grande escala. Também visa controlar o risco, adotando assim uma
abordagem cíclica crescente e aumentando os benefícios de outros modelos.
Cada versão possui um processo de prototipagem que pode ser usado como
mecanismo de redução de risco por meio do feedback do usuário. Além disso, o
formato do processo é um conjunto de loops espirais, onde o loop interno é visto
como a primeira versão do programa, que se refere ao conceito inicial do
produto. Existem linhas divisórias em cada espiral. Eles são:
• Definição de objetivos: Determinar os objetivos específicos para a fase
do projeto, identificando restrições e riscos do projeto e elaboração de um plano
gerencial detalhado.
• Avaliação e redução de riscos: Os riscos do projeto são analisados
singularmente e são tomadas medidas de redução dos riscos.
• Desenvolvimento e validação: Após avaliado os riscos, tem-se a
escolha do modelo de desenvolvimento adequado.
• Planejamento: O projeto é revisado, também é feito a decisão se há
necessidade de mais um espiral ao redor do modelo atual. Se sim, o plano é
elaborado para prosseguir.
Segundo SOMMERVILLE :combina prevenção e tolerância a mudanças,
assume que mudanças são um resultado de riscos de projeto e inclui atividades
explícitas de gerenciamento de riscos para sua redução”.
Modelo de Processo baseado em Componentes

O desenvolvimento baseado em componentes permite que o sistema

final seja tratado como vários “minissistemas”, diminuindo sua complexidade e
permitindo que cada componente empregado seja focado em apenas uma
funcionalidade ou um conjunto de funcionalidades semelhantes. Deste modo,
estas funcionalidades podem ser reutilizadas em diversas aplicações através
do acesso ao componente
Entretanto, a utilização de componentes requer uma nova forma de
pensar da equipe do projeto. Arquitetos, analistas e programadores devem
preocupar-se agora com a integração do sistema com os componentes que
serão utilizados, necessitando assim de uma atenção maior na definição de
interfaces internas e externas. Esses pontos podem gerar mudanças no
processo de desenvolvimento utilizado.
O modelo de processo baseado em componentes é usado caso nenhum
sistema adequado esteja disponível. Com isso, passa a ter o reaproveitamento
de componentes de sucesso no mercado que atendem às necessidades da
empresa. Lembre-se de que este é um sistema personalizado e não padrão.
Para a aplicação deste processo são utilizadas algumas etapas como:
1. Procurar por produtos e avaliar os componentes disponíveis, assim
verificando a aplicação em campo.
2. Considerar a integração dos itens.
3. Projetar uma arquitetura, com finalidade de acomodar os
componentes
4. Integrar os componentes na arquitetura.
 5. São realizados testes, assim assegurando a funcionalidade.

Modelo de Desenvolvimento Concorrente

Este modelo pode ser adaptado a qualquer um dos modelos de

desenvolvimento de software, servindo assim como uma ferramenta de
monitoramento do andamento de cada fase determinada do projeto. Ele
representa elementos simultâneos e iterativos da série de eventos que irão
disparar as transições de estado encontradas em cada atividade, ação ou
tarefa de engenharia de software. Ele também fornece uma imagem precisa do
status atual de um projeto, definindo-o com alguns termos como:
• Inativo: Fica no aguardo na conclusão da tarefa anterior, assim quando
concluída migra para estado de desenvolvimento.
• Em desenvolvimento: Trata-se do status que denomina a equipe
trabalhando no projeto.
• Concluído: Assim que a tarefa é finalizada, migra para o estado de
concluído a etapa.
• Aguardando modificações: Trata-se de um estado que o cliente solicita
a mudança dos requisitos e assim que finalizadas as atividades, migram para o
estado de concluído.
Processo Unificado

O Processo Unificado (PU) é uma tentativa de reunir as melhores

características dos modelos convencionais de processo de software, através do
reconhecimento da importância da comunicação com o cliente e de métodos
diretos para a descrição da visão do cliente.
O PU pode ser utilizado em projetos de pequeno e grande porte,
independentemente da complexidade do problema. Tem como objetivos
principais: atender as necessidades dos clientes e acompanhar riscos. A
abordagem é composta por quatro fases: concepção, elaboração, construção e
transição.

• Fase de concepção: considerada uma fase de business case para um sistema

que visa a comunicação com o cliente e o desenvolvimento do planejamento
iterativo e incremental do projeto. São descritas as principais características e
funcionalidades de cada categoria solicitada pelo usuário, juntamente com a
identificação de recursos e riscos e a criação dos cartões.
• Fase de elaboração: desenvolver um melhor entendimento do problema
prevalecente, selecionar a estrutura adequada para o sistema, identificar os
principais riscos do projeto e desenvolver o plano do projeto.
• Fase de construção: Como resultado das atividades do modelo arquitetônico,
testes de unidade são desenvolvidos e executados para cada modelo. Se
passar durante o teste, o software logo será lançado em beta para os usuários.
• Fase de Transição: Por se tratar de um resumo das demais fases anteriores,
após o lançamento do software, ele buscará e fornecerá feedback aos usuários
para que façam as alterações necessárias. Além de criar material de suporte
ao usuário.
• Fase de produção: inclui o monitoramento contínuo do software e, portanto, o
suporte do ambiente operacional. A funcionalidade também é verificada por
meio de relatórios de bug e solicitações de mudança.

Norma NBR 12207

A ISO/IEC 12207[1] é a norma ISO/IEC que define processo de Engenharia de

Software, atividades e tarefas que são associados com os processos do ciclo
de vida do software desde sua concepção até a sua obsolescência ou
descontinuidade.
Ela estabelece uma estrutura comum para os processos de ciclo de vida e de
desenvolvimento de software visando orientar as organizações a
compreenderem todos os componentes presentes na aquisição,
desenvolvimento e fornecimento de software e, assim, conseguirem firmar
contratos e executarem projetos de forma mais eficaz.
Processo de aquisição: Busca definir as necessidades do adquirente de um
sistema, produto ou serviço de software. Logo, utiliza as atividades de
preparação de pedido da proposta, preparação e atualização do contrato,
monitoramento do fornecedor e aceitação e conclusão do contrato.
• Processo de fornecimento: Iniciada pela decisão de preparar uma proposta,
com intuito de responder a um pedido de proposta de um cliente por meio do
contrato e assim fornece um sistema, produto de software ou serviço de
software.
• Processo de desenvolvimento: Durante esse processo, tem-se a realização
de análises de requisitos, projeto, codificação, integração, prototipação, testes
e instalação do software.
• Processo de operação: Este processo cobre a operação do produto de
software e o suporte operacional aos usuários. Assim abrangendo a
implementação do processo, teste operacional, operação do sistema e suporte
ao usuário.
• Processo de manutenção: Esse processo atende a adaptações e
modificações do código e documentação, ambos sendo associados a
problemas encontrados ou necessidades do cliente. A princípio tem o objetivo
de modificar o produto de software existente, com isso irá preservar a
integridade do software.
• Processo de apoio de ciclo da vida: Tem como foco a garantia da existência
do processo funcional. Assim utiliza algumas ferramentas como documentação,
gerencia de configuração, garantia de qualidade, verificação, revisão conjunta,
auditoria e resolução de problemas.
• Processo organizacional do ciclo da vida: Trata-se de outro processo que foca
na garantia do processo funcional, mas utiliza de outras ferramentas
divergentes da anterior, como os processos de gerência, infraestrutura,
melhoria e treinamento.

Considerações finais

Este trabalho foi realizado com base na investigação de alguns modelos

do processo evolutivo, os quais tendem a ter melhor resolução de problemas e
menos limitações do que o modelo em cascata. De acordo com o artigo de
Barry Boehm, todos os modelos são baseados no modelo em cascata, mas
requerem vários ajustes evolutivos para atender à demanda e ao propósito do
ambiente de desenvolvimento de software.
Além das observações e dados citados pelo autor, nota-se que o modelo
espiral é o mais amplamente utilizado hoje, pois os pontos fortes dos outros
modelos anteriores são usados \u200b\u200bem conjunto com o modelo em
cascata em grande escala.
No ambiente atual de processo de desenvolvimento de software, é utilizada a
norma NBR 12207, que seria o acordo de certificação com o cliente e os
requisitos de software, criando uma relação de confiança entre o cliente e a
empresa desenvolvedora do programa. Além de selecionar o modelo de
desenvolvimento de software certo para o produto.
Por fim, a utilização da norma NBR 12207 juntamente com o modelo espiral
pode ser uma excelente opção para o desenvolvimento de software, pois a
qualidade do produto e a manutenção estão no centro.
Referências

https://www.devmedia.com.br/desenvolvimento-baseado-em-componentes-
revista-java-magazine-110/26550
http://www.uel.br/cce/dc/wp-content/uploads/VersaoPreliminarTCC-
TaniaEishima.pdf
https://www.abntcatalogo.com.br/norma.aspx?ID=356662
https://blog.grancursosonline.com.br/t-i-em-foco-iso-iec-12207/
SOMMERVILLE, I. Engenharia de Software. 9.ed. São Paulo: Editora Pearson
Brasil, 2011.
PRESSMAN, Roger S. Engenharia de software. 7.ed. São Paulo: McGraw-Hill,
ArtMed, 2011.
Boehm, B. “A Spiral Model of Software Development and Enhancement “1998
Norma NBR ISO 12207- ABNT