Introdução À Engenharia de Software

1
ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

2
Núcleo de Educação a Distância
PRESIDENTE: Valdir Valério, Diretor Executivo: Dr. Willian Ferreira.
O Grupo Educacional Prominas é uma referência no cenário educacional e com ações voltadas para
a formação de profissionais capazes de se destacar no mercado de trabalho.
O Grupo Prominas investe em tecnologia, inovação e conhecimento. Tudo isso é responsável por
fomentar a expansão e consolidar a responsabilidade de promover a aprendizagem.
GRUPO PROMINAS DE EDUCAÇÃO

Diagramação: Gildenor Silva Fonseca
3
Prezado(a) Pós-Graduando(a),
Seja muito bem-vindo(a) ao nosso Grupo Educacional!

Inicialmente, gostaríamos de agradecê-lo(a) pela confiança
em nós depositada. Temos a convicção absoluta que você não irá se
decepcionar pela sua escolha, pois nos comprometemos a superar as
suas expectativas.
A educação deve ser sempre o pilar para consolidação de uma
nação soberana, democrática, crítica, reflexiva, acolhedora e integra-
dora. Além disso, a educação é a maneira mais nobre de promover a
ascensão social e econômica da população de um país.
Durante o seu curso de graduação você teve a oportunida-

de de conhecer e estudar uma grande diversidade de conteúdos.
Foi um momento de consolidação e amadurecimento de suas escolhas
pessoais e profissionais.
Agora, na Pós-Graduação, as expectativas e objetivos são
outros. É o momento de você complementar a sua formação acadêmi-
ca, se atualizar, incorporar novas competências e técnicas, desenvolver
um novo perfil profissional, objetivando o aprimoramento para sua atua-
ção no concorrido mercado do trabalho. E, certamente, será um passo
importante para quem deseja ingressar como docente no ensino supe-
rior e se qualificar ainda mais para o magistério nos demais níveis de
ensino.
E o propósito do nosso Grupo Educacional é ajudá-lo(a)
nessa jornada! Conte conosco, pois nós acreditamos em seu potencial.
Vamos juntos nessa maravilhosa viagem que é a construção de novos
conhecimentos.
Um abraço,
Grupo Prominas - Educação e Tecnologia
4
5
Olá, acadêmico(a) do ensino a distância do Grupo Prominas!..
É um prazer tê-lo em nossa instituição! Saiba que sua escolha

é sinal de prestígio e consideração. Quero lhe parabenizar pela dispo-
sição ao aprendizado e autodesenvolvimento. No ensino a distância é
você quem administra o tempo de estudo. Por isso, ele exige perseve-
rança, disciplina e organização.
Este material, bem como as outras ferramentas do curso (como
as aulas em vídeo, atividades, fóruns, etc.), foi projetado visando a sua
preparação nessa jornada rumo ao sucesso profissional. Todo conteúdo
foi elaborado para auxiliá-lo nessa tarefa, proporcionado um estudo de
qualidade e com foco nas exigências do mercado de trabalho.
Estude bastante e um grande abraço!
Professora: Jéssica Laisa Dias da Silva
6
O texto abaixo das tags são informações de apoio para você ao
longo dos seus estudos. Cada conteúdo é preprarado focando em téc-
nicas de aprendizagem que contribuem no seu processo de busca pela
conhecimento.
Cada uma dessas tags, é focada especificadamente em partes
importantes dos materiais aqui apresentados. Lembre-se que, cada in-
formação obtida atráves do seu curso, será o ponto de partida rumo ao
seu sucesso profisisional.
7
Tivemos o surgimento da Engenharia de Software com o mar-
co ao longo da história do software, que foi a crise de software, na dé-
cada de 70, que tinha problemas como: a falta de um processo de
desenvolvimento do software, a ausência de uma estrutura para nortear
as equipes, a falta de mão de obra capacitada para atender a demanda.
Conforme o conceito da IEEE - Institute for Electrical and Electronics
Engineers, a Engenharia de Software, é definida de modo abrangente,
como um campo da ciência que fornece todo o modelo para a criação
e manutenção de software. Neste módulo iremos estudar sobre a En-
genharia de Software, bem como toda sua contextualização, princípios
e estrutura. No decorrer dos capítulos será discorrido sobre os tipos
modelos de processo de desenvolvimento, apresentação das técnicas

de levantamento de requisitos, como o que viabiliza ou não a produção
do software. O resultado do trabalho é a constatação de um bom plane-
jamento do processo de software e como entender bem os processos
existentes para encaixá-los adequadamente na produção de um deter-
minado sistema.
Engenharia de Software; Processo e desenvolvimento.
8
Apresentação do Módulo ______________________________________ 11
CAPÍTULO 01
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Contextualização e Histórico ___________________________________ 13
Problemas Atuais ______________________________________________ 16
Relevância na Área de TI _______________________________________ 19
Processo do Software __________________________________________ 21
Recapitulando _________________________________________________ 27

CAPÍTULO 02
MODELOS DE PROCESSOS DE DESENVOLVIMENTO
DE SOFTWARE
Histórico de Evolução dos Modelos de Processos de Software ___ 32
Processos Ágeis ________________________________________________ 40
Recapitulando _________________________________________________ 49
CAPÍTULO 03
REQUISITOS DE ENGENHARIA DE SOFTWARE
Requisito de Engenharia de Software: Conceituação ____________ 54
Documento de Requisitos _____________________________________ 61
Testes e Revisão de Software ___________________________________ 65
9
Recapitulando _________________________________________________ 68
Considerações Finais ___________________________________________ 72
Fechando a Unidade ___________________________________________ 73
Referências ____________________________________________________ 76
10
Com a evolução da tecnologia e dos softwares ao logo do tem-
po, temos a Engenharia de Software, ciência que surgiu para contri-
buir no processo de desenvolvimento do software, que ainda é definida
como um processo, que contém um conjunto de métricas e práticas,
tendo ferramentas que permitem aos profissionais criarem software de
boa qualidade.
Sendo assim, é de suma importância na área tecnológica es-
tudar sobre a Engenharia de Software, trazendo sua contextualização,
importância e avanço ao longo do tempo. Além também entender sobre
os seus princípios, fundamentações e seus processos, que contribuem
para produzir softwares com qualidade e atender assim às necessidades
e demandas do mercado.
Desse modo, o capítulo 1 abordará a introdução sobre Enge-
nharia de Software, trazendo um breve histórico e a contextualizando;
o capítulo 2 versará sobre os modelos de desenvolvimento de software,
trazendo os tipos, exemplificando cada um, finalizando com a concei-
tuação do software como produto; e por fim, o capítulo 3 abordará so-
bre o levantamento de requisitos e as técnicas para adquiri-los, como
também versará sobre os pontos para viabilizar um desenvolvimento de
software e a contextualização da fase de implantação e manutenção.

No mais, boas-vindas ao presente módulo e que todos possam
enriquecer seus conhecimentos com os assuntos que serão explana-
dos.
Bons estudos!
11
INTRODUÇÃO À
ENGENHARIA DE SOFTWARE
Com o passar do tempo, observamos o desenvolvimento dos

softwares que estão presentes em varías áreas, passando pela indús-
tria, saúde, até a educação, eles estão presentes no cotidiano das pes-
soas. Importante compreender que o software é formado por algoritmos
que, quando executado, tem como resultado atributos, funções e per-
formance desejados, ou seja, estruturas de dados que permitem aos
programas alterar informações de modo adequado.
Além disto, quanto à presença massiva do software, faz-se
necessário controlar e gerenciar o aprimoramento dos que são desen-
volvidos, como também os que já existem, em que é preciso analisar
e garantir a manutenção e/ou evolução para atender às necessidades
que cada dia surge no mercado.
Dessa forma, surgiu a Engenharia de Software que nada mais
é que a engenharia que trabalha com os processos para desenvolver
softwares. O autor Pressman (2016) relata que a Engenharia de Sof-
tware é um processo que contém um conjunto de métricas e práticas
12
tendo ferramentas que permitem aos profissionais criarem software de
qualidade elevada (PRESSMAN, 2016).
Conceitua ainda que a Engenharia de Software, é definida de
modo abrangente, como um campo da ciência que fornece todo modelo
para a criação e a manutenção de software (IEEE, 2004).
Ainda podemos afirmar que a engenharia de software, está vol-
tada a criar e a usar conceitos concretos da engenharia, com a finalida-
de de produzir softwares econômicos, que proporcionem que tenham
maior confiabilidade e que trabalhem de modo eficiente (PRESSMAN,
2006).
O software tem uma grande importância, porque este é res-

ponsável por disponibilizar a informação, que é produto mais desejado
da nossa época. Pois, hoje as empresas utilizam da informação para
aumentar suas receitas, quem tem informação tem o poder no mundo
empresarial. Daí tiramos a potência que é adotar a Engenharia de Sof-
tware para promover a criação de software bem projetado para atender

às necessidades das empresas e dos seus clientes.
CONTEXTUALIZAÇÃO E HISTÓRICO
A evolução do software no decorrer do tempo foi marcada do

seguinte modo, no período 1950-1965 o hardware teve muita evolução,
este não era visto como um elemento importante, por isso, havia pou-
cos métodos e práticas ordenadas para o desenvolvimento de software.
Como também o hardware era caracterizado no contexto generalizado
e produzido com funcionalidades específicas para cada aplicação e ha-
via falta de documentação dos sistemas desenvolvidos.
Logo após, os anos entre 1965 a 1975 foram marcados pela
multiprogramação, sistemas multiusuários, sistema operacional de tem-
po real. Como também este período foi caracterizado pela primeira ge-
ração dos sistemas de gerenciamento de banco de dados (SGBD’s),
ainda pelo desenvolvimento de produto de software como fábrica de
software e bibliotecas de software. Além disso, houve aumento na de-
manda para produção dos sistemas.
Vale ressaltar que a denominação Engenharia de Software foi
13
designada no ano 1960 e usada de forma oficial em 1968 na NATO
Science Committee. A idealização deste termo se deu devido a uma
necessidade de solucionar a crise com os softwares, que era de possibi-
litar um ambiente de trabalho sistemático, que proporcionasse a criação
de softwares mais complexos, comum à maior exigência de qualidade e
controle para atender as necessidades que surgiam.
A crise de software, desta década de 70, se deu devido a pro-
blemas como: a falta de um processo de desenvolvimento do software,
a ausência de uma estrutura para nortear as equipes, a falta de mão de
obra capacitada para atender à demanda.
Deste modo, com a falta de um processo claro e específico
a ser seguido, dificultava as equipes de tomar decisão que realmen-
te atendesse aos clientes, como também de proporcionar a garantia
de uma manutenção e alteração ao software, devido à dificuldade de
gerenciar o que já se tinha pronto. Como também altos custos e baixa
confiabilidade.
Em suma um problema comum nesta crise era a preocupação,
mas com a programação, ao invés de primar e aplicar apropriadas prá-
ticas que permitissem resolver a complexidade na implementação dos
sistemas, como contribuir no gerenciamento destes.
Com isto, a Engenharia de Software veio proporcionar um pro-
cesso sistemático para produção de software, alinhando os conceitos

conhecidos e usados na área de engenharia para desenvolvê-los de
modo mais eficaz e controlados.
Por isto esta tem uma grande importância para ser estudada
em nossas universidades, pois, a Engenharia de Software trata de ser
uma disciplina da ciência da computação que viabiliza processos, me-
todologias e ferramentas para desenvolver e sustentar softwares com
qualidade elevada para a resolver problemas.
Atualmente, os softwares evoluíram e encontramos eles em di-
versos setores e sendo utilizados para muitos fins, tivemos os avanços
na tecnologia, trazendo as linguagens orientadas a objetos, sistemas
especialistas, de inteligência artificial, sistema de apoio a decisão, com-
putação paralela, entre outros.
Que por mais que tenha dito uma a crise de software na déca-
da 60, que motivou a criação da Engenharia de Software, isso não im-
plica afirmar que agora não existe mais problemas no desenvolvimento
do software.
14
Temos assim, que a Engenharia de Software trabalha com al-
gumas camadas e está diretamente relacionada à qualidade, ao apri-
moramento dos procedimentos, assim como a melhorias da disciplina.
Esta fornece assim material para a criação dos produtos de software,
independente da área trabalhada. Abaixo temos a figura que ilustra es-
sas camadas.
Figura 1- Camadas da Engenharia de Software
FERRAMENTAS
MÉTODOS
PROCESSOS
FOCO NA QUALIDADE

FONTE: A autora, 2020.
Temos assim a explicação de cada uma das camadas ilustrada

acima:
• Processo (Como aplicar?): Este é responsável, como base
para a Engenharia de Software, por conectar os processos às ferra-
mentas, de modo que assim viabilize a produção do software, seguindo
um prazo estabelecido. Também trata dos métodos e ferramentas que
serão adotados.
• Métodos (Como fazer?): Estes são referentes a viabilizar os
procedimentos, atividades de acordo com as diferentes fases do de-
senvolvimento para o processo de produzir softwares. Alguma dessas
atividades são por exemplo: planejar e estimar tempo do projeto, teste,
codificação, manutenção, levantamento/análises de requisitos, modela-
gem de projeto e suporte.
• Ferramentas (Como automatizar?): a Engenharia de Softwa-
re viabiliza ferramentas automatizadas (Computer Aided Software En-
gineering) ou semiautomatizadas para os procedimentos e práticas de
criação do software, existem diversas ferramentas para os processos.
Temos a Upper-CASE que são as ferramentas de suporte, designadas
às tarefas na fase inicial do processo e temos Lower-CASE que são as
15
ferramentas de apoio às tarefas mais complexadas, como programar,
depurar e testes. Essas ferramentas contribuem para uma maior produ-
tividade dos envolvidos no projeto.
A Engenharia de Software além de oferecer essa série de mé-
todos e técnicas agregadas a metodologias, ainda por meio do desen-
volvimento de ferramentas, também é composta tarefas como teorias e
princípios, alguns princípios são citados abaixo:
• Modularidade: Refere-se a dividir sistemas complexos para
poder atender à resolução de um problema, para gerar melhor entendi-
mento. Trabalhando com a decomposição e a composição, em que uma
é a ação de decompor um problema original em problemas menores,
recursivamente. Já a composição é a ação de juntar os elementos com-
ponentes de um problema.
• Abstração: Refere-se a realizar a separação dos conceitos
para gerar uma melhor compreensão de um problema.
• Generalidade/Especialidade: Refere-se a observar se diante
da solução de um problema e poder generalizar a resposta para outros.
Este princípio tende até um maior custo e exige uma robustez do sof-
tware.
• Rigor e formalidade: Refere-se a primar por uma integridade
no processo do software para gerar precisão e confiabilidade. Com re-
lação à formalidade é referente a um processo que seja direcionado a

usar leis matemáticas.
• Incrementação: Refere-se ao processo de alterar ou acres-
centar algum elemento no software de modo incremental, contribuindo
na evolução no software.
• Antecipação de mudanças: Refere-se a preparar a produção
do software para possíveis mudanças solicitadas no futuro. Esta ante-
cipação é importante porque muitos requisitos podem ainda não serem
entendidos no início do desenvolvimento, como pode haver surgimento
e alteração de requisitos durante o processo de desenvolvimento.
PROBLEMAS ATUAIS
Na seção anterior foi explicado como surgiu a Engenharia do

Software e sua grande contribuição, que propicia um desenvolvimento
de softwares com mais eficiência e atende às necessidades dos clien-
tes.
Porém, mesmo tendo o seu surgimento marcado com esta con-
tribuição, muitos problemas ainda continuando existindo nesta área, de-
vido às exigências que cada dia mais vêm aumentando com os avanços
16
das tecnologias. Por mais que existam novas técnicas de engenharia de
software, as demandas e exigências continuam a crescer progressiva-
mente, sempre exigindo do processo de desenvolvimento.
Outro desafio atual é que existem diversas tecnologias con-
tribuindo para desenvolver softwares rapidamente, fazendo com que
algumas empresas, na pressão de entregar o produto, não utilize as
práticas e processo de engenharia adequados. Deste modo, por muitos
serem desenvolvidos assim, acabam por não realizar documentação,
fazer levantamentos de requisitos de modo adequado, gerando assim a
criação softwares fracassados que não garantem confiabilidade e com
um custo alto.
Então, hoje ainda temos muitos problemas com softwares que
começam a ser e desenvolvidos e no meio do processo são abandona-
dos, até mesmo antes de serem finalizados.
Podemos citar alguns problemas como:
• Prazo de entrega de produtos não cumpridos, por conta de
serem definidos de modo errado;
• Falta de documentação;
• Falta de comunicação entre os envolvidos no projeto;
• Custo dos projetos não estipulados de modo correto;
• Falta de teste de software.

Observe a tirinha da figura 2, abaixo representa bem um pro-
blema muito comum no processo de desenvolvimento do software.
Figura 2- Tira do Balanço
FONTE: (FALBO, 2005)

17
Podemos inferir analisando a tirinha acima, da figura 2, que
quando o cliente pede um produto e recebe outro totalmente diferente,
percebe-se que cada imagem ilustrada, apresenta algo diferente do ba-
lanço pedido e, logo após, podemos ver na tirinha como os membros da
equipe entendem o projeto pedido. O grande problema disto, na prática,
é que acarreta projetos de softwares fracassados, pois, acabam por ter
custo alto e exigir um tempo de entrega maior.
Assim, vemos atualmente que muitos projetos são até descar-
tados no meio do processo, por conta de levarem tanto tempo para
serem projetados, que acabam se tornando obsoleto, muitas vezes isso
se deve pela equipe não entender o que realmente foi solicitado pelo
cliente, e acaba ficando obsoleto. Por isso, é tão importante seguir os
princípios de Engenharia de Software.
Alguns mitos também contribuem para gerar problemas no pro-
cesso de desenvolvimento como:
• Mito do Cliente 1: Acreditar que o software é flexível e qual-
quer momento pode ser solicitada mudança e que facilmente pode ser
implementada.
• Por outro lado, na realidade é bem diferente, pois, uma alte-
ração pedida durante o desenvolvimento do software tardiamente pode
gerar um custo alto, do que se fosse pedida na fase inicial.
• Mito do Cliente 2: Acreditar que é suficiente realizar apenas

um esboço geral das metas do software para iniciar e implementá-lo.
Inferindo que depois pode atender aos detalhes para desenvolver o sof-
tware.
• Por outro lado, a realidade é bem diferente, pois, um bom
levantamento na fase inicial, do que será necessário para escrever o
software, é de suma importância para evitar insucesso mais tarde. É im-
portante atentar-se aos detalhes e uma elaboração técnica, isto na fase
inicial, descrevendo os pontos como: funcionalidade, execução, limita-
ção, validação, interface. Assim, na prática, definindo de modo errôneo
no início é o principal motivo de insucesso da criação do software.
• Mito Profissional 1: Acreditar que implementar o programa e o
colocar para funcionar é suficiente para afirmar que o trabalho foi con-
cluído.
• Por outro lado, na realidade é que o software pode requer um
maior custo após estar pronto, como manutenção e alteração de algum
requisito.
• Outro Mito Profissional 2: Acreditar que não tem modo para
analisar a qualidade sem ter o software “trabalhando”.
• Por outro lado, na realidade é que pode manter uma garantia
de software com qualidade, por meio da revisão dos elementos levanta-
18
dos no início do processo, ou seja, realizar uma revisão técnica formal.
Podemos observar como esses mitos são um problema e po-
dem prejudicar o processo de desenvolvimento do software. Sendo as-
sim, grandes fatores para o fracasso dos softwares, são casos que não
sejam levados em consideração pelas equipes envolvidas no processo.
Por mais que ao longo tempo o software tenha evoluindo, ain-
da continuam existindo limitações, como aptidão em desenvolver um
software deixa a desejar em relação à potencialidade do hardware. O
custo alto para produzir software confiável e de qualidade. Além do que
para manter os programas existentes é abordado por projetos que não
se encaixam adequadamente.
A comunicação contribui para evitar problemas na produção do

software, pois, esta é um forte elemento para desenvolver com qualida-
de e com custo menor. Esta é um elemento importante, tanto para a re-
lação entre o cliente e o engenheiro, como também do engenheiro com
a equipe envolvida no projeto. Para assim, contribuir para um processo

de Engenharia de Software que gere um software realmente eficiente.
RELEVÂNCIA NA ÁREA DE TI
Oliveira (2009) relata que atuar na área da Tecnologia da In-

formação de modo rápido, versátil e inovador torna-se cada vez mais
indispensável para o bom êxito do negócio.
Estamos inseridos atualmente num cenário totalmente voltado
à área de tecnologia, passando dos setores industriais ao pessoal. Pois,
hoje temos variados softwares no campo pessoal, em que as pessoas
cada dia buscam mais, no campo da saúde temos vários softwares aju-
dando na tomada de decisão, como também nos campos da educação
e da segurança.
Antes a tecnologia estava só inserida nas indústrias, porém,
hoje ela é um importante elemento para diferentes áreas. Em suma,
a TI viabiliza as empresas profissionais com uma maior habilidade para
expandir, receber, alterar e disponibilizar a informação, sendo um forte
meio para agregar valor às diversas áreas.
Dessa forma, a área TI perpassa por importantes meios, como
19
por exemplo na área do desenvolvimento de software, que é de grande
contribuição por viabilizar a produção deste, de alta qualidade e com
grande performance, devido a cada dia não bastar apenas software
pronto, mas é exigindo uma melhor performance.
Podemos observar que as organizações que apresentam bons
êxitos e inovação entendem a TI como área que possibilita a idealização
e o gerenciamento das estratégias de negócio.
Atuação profissional
A área de atuação dos engenheiros de software é de suma
importância, pois, estes profissionais têm a responsabilidade de realizar
e garantir que aconteçam os processos e as práticas que envolvidas
neste procedimento.
Vale ressaltar que as Diretrizes Curriculares de Computação
definem as aptidões técnicas para o engenheiro de software, algumas
delas são práticas como: de analisar, especificar, desenvolver, testar e
realizar a manutenção de software, como também de escolher tecno-
logias apropriadas para a criar um software (Sociedade Brasileira de
Computação, 2015).
As Diretrizes Curriculares de Computação definem as compe-
tências que o engenheiro de software deve atender, sendo algumas de-

las: (Sociedade Brasileira de Computação, 2015)
“Analisar e selecionar tecnologias adequadas para a construção de software;

Avaliar a qualidade de sistemas de software; Integrar sistemas de software;
Gerenciar projetos de software conciliando objetivos conflitantes, com limita-
ções de custos, tempo e com análise de riscos; Aplicar adequadamente nor-
mas técnicas; Qualificar e quantificar seu trabalho baseado em experiências
e experimentos; Exercer múltiplas atividades relacionadas a software, como:
desenvolvimento, evolução, consultoria, negociação, ensino e pesquisa;
Conceber, aplicar e validar princípios, padrões e boas práticas no desenvolvi-
mento de software; Analisar e criar modelos relacionados ao desenvolvimen-
to de software; Identificar novas oportunidades de negócios e desenvolver
soluções inovadoras.”
Vale ressaltar que existe um Código de ética e práticas profis-

sionais da Engenharia de Software, que foi criado de modo conjunto da
ACM- Association for Computing Machinery, (ACM,1999). Os códigos
criados pela organização estão relacionados à profissional especialista
em computação. Segue abaixo uma versão resumida de como este có-
digo está composto, trazendo os oito princípios que os engenheiros de
software devem se responsabilizar: (ACM, 1999)
20
1. PÚBLICO — Engenheiros de software precisam atuar con-
forme a necessidade do público.
2. CLIENTE E EMPREGADOR — Engenheiros de software
precisam atuar de modo que satisfaçam à necessidade de seu cliente e
empregador e conforme a necessidade do público.
3. PRODUTO — Engenheiros de software precisam viabilizar,
de modo confiante, que seus produtos e alterações solicitados alcan-
cem um elevado padrão profissional.
4. JULGAMENTO — Engenheiros de software precisam ter
uma postura profissional garantindo a integridade e a independência.
5. GERENCIAMENTO — Gerentes e líderes de Engenharia de
Software precisam primar e motivar por uma postura ética para realizar
o trabalho de gerenciar e dar suporte ao software.
6. PROFISSÃO — Engenheiros de software precisam aperfei-
çoar a postura e a imagem da profissão conforme a necessidade do
público.
7. COLEGAS — Engenheiros de software precisam se dispor
a ajudar e ser íntegros.
8. SI PRÓPRIO — Engenheiros de software precisam promo-
ver sua aprendizagem contínua durante toda a vida, e sempre primar
por uma postura ética para viver a profissão.

Cada dia mais, as grandes empresas estão requisitando enge-
nheiros de software, profissão que vem crescendo muito, pois, para ga-
rantir bons projetos de software, é necessário mão de obra qualificada
e que possa atender aos princípios da Engenharia de Software, como
citados na seção.
PROCESSO DO SOFTWARE
Na Engenharia de Software, também conhecida como proces-

so de software, um processo de software é um conjunto de atividades
que altera o desenvolvimento de um produto de software. As quatro
tarefas fundamentais básicas a todos os processos de software estão
descritas abaixo:
1. Especificação de software: as definições solicitadas pelos
21
clientes e validadas com os engenheiros para direcionar como será o
software.
2. Desenvolvimento de software: referente à criação do softwa-
re, como é projetado e programado.
3. Validação de software: prática para verificar se o software
desenvolvido está de acordo com o que foi solicitado pelo cliente.
4. Evolução de software: prática para proporcionar que o sof-
tware possa ser alterado sem muito custo, caso o cliente necessite ou o
mercado exija alguma adequação.
Com isto, entendamos o processo de software como práticas,
tarefas e ações que colaborem para desenvolver softwares com qua-
lidade e que cumpram o prazo determinado pelo cliente, para assim,
viabilizar um serviço que satisfaça as partes envolvidas e cumpra a es-
pecificações solicitadas.
Além do que, o processo tem como finalidade gerar estrutura-
ção das tarefas referentes à idealização dos softwares, primando res-
ponder questões como: quando realizar cada atividade, como realizar
e por quem as atividades envolvidas no processo de desenvolvimento
serão executadas.
Vale ressaltar que, conforme Pressman (2011) relata um pro-
cesso genérico para Engenharia de Software que consiste em cinco
tarefas como: comunicação, planejamento, modelagem, construção e

entrega.
• Comunicação: é de suma importância antes de iniciar o pro-
cesso estabelecer uma boa comunicação e entendimento entre os en-
volvidos do projeto com o cliente. Para que assim haja um bom enten-
dimento dos objetivos e as funcionalidades que devem ser elaboradas
• Planejamento: é de suma importância estruturar de maneira
planejada o projeto de software. Devido este ser uma atividade com-
plexa, que requer organização para poder dirigir a equipe. Esta orga-
nização é o processo do projeto de software que é determinado pela
Engenharia de Software, tratando de definir atividades, métodos a se-
rem administrados, os pontos de limitação, os elementos que serão pre-
cisos, o cronograma dos trabalhos e os resultados finais do produto.
• Modelagem: é de suma importância no processo do softwa-
re ter um esboço que dará uma ideia do todo, para assim entender as
necessidades do projeto. Assim temos a criação de alguns modelos na
Engenharia de Software que norteia a equipe envolvida e contribui para
atender às necessidades do cliente e dos envolvidos.
• Construção: esta tarefa corresponde a juntar e gerar código
manual ou automatizado, com ação de testes para analisar e ver erros
no código.
22
• Emprego ou entrega: esta tarefa é referente à entrega do sof-
tware em que o cliente analisa e determina se necessita de alguma
alteração. Na entrega, o cliente valida e dá o feedback por meio do que
foi analisado.
Assim, podemos compreender que essas cinco tarefas gerais,
permitem ser usadas para o desenvolvimento de softwares com dife-
rentes características de grande ou pequeno softwares. Tendo como
diferença as aplicações desenvolvidas e os detalhes no processo, po-
rém, as tarefas metodológicas são iguais e são executadas no projeto à
medida que ele se desenvolve.
Entenda que o processo software não é uma “receita de bolo”

a ser apenas seguida e inalterada, ele deve ser entendido como con-
junto de métodos e práticas que a equipe de software envolvida pode
analisar e decidir qual métodos e ações se encaixam melhor ao projeto
desenvolvido.

As atividades metodológicas do processo de Engenharia de
Software são complementadas por uma série de atividades de apoio;
em geral, estas são aplicadas ao longo de um projeto, ajudando a equi-
pe a gerenciar, a controlar o progresso, a qualidade, as mudanças e o
risco. Conforme (PRESSMAN, 2011) determina, algumas as atividades
de apoio como:
• Controle e acompanhamento do projeto: permite a equipe
analisar o projeto em relação ao seu andamento, conforme o planeja-
mento para viabilizar o cumprimento do cronograma e fazendo o que for
necessário para este fim;
• Administração de riscos: essa atividade é referente a analisar
os riscos que possam prejudicar a entrega final ou a qualidade do sof-
tware. É responsável por definir as tarefas de qualidade e garantir seu
cumprimento no software;
• Revisões técnicas: essa atividade é referente a analisar os
elementos de Engenharia de Software, avaliando se existe erro para
evitar que eles passem para próxima tarefa;
• Medição: essa atividade está associada a contribuir para en-
trega dos softwares, conforme o que foi solicitado; responsável por de-
cidir e coletar elementos durante o processo de software;
23
• Gerenciamento da configuração de software: essa atividade é
responsável por controlar as implicações durante o processo;
• Gerenciamento da reusabilidade: essa atividade é referente
a estabelecer pontos para reutilizar os elementos e componentes do
software, como por buscar elementos que possam ser reutilizados;
• Preparo e produção de artefatos de software: essa atividade
é referente a incorporar as tarefas precisas para elaborar os artefatos.
Exemplificando: formulários, documentos, logs, modelos e listas.
Relatamos antes que o processo de Engenharia de Software
não é como receita fixa, que deve apenas ser seguida como instrução.
Porém, é necessário que seja um processo flexível e que possa ser
alterado quando necessário, caso haja a necessidade de alguma mu-
dança, como algum problema surja durante o desenvolvimento. Assim,
o processo de um projeto varia de um para outro, porque depende muito
da especialidade e da necessidade.
Conceituação de Software como produto

É importante entender a definição e a conceituação do software
como produto, conforme Sommerville (2007), software é o programa,
porém, também a documentação e a configuração são relacionadas e
precisas para que o programa trabalhe de modo correto. Contudo, um

sistema de software incide sobre um conjunto de programas à parte;
arquivos de configuração; documentação do sistema, que descreve a
estrutura do sistema; a documentação do usuário, que explica como
usar o sistema.
Compreende que um produto de software, por outro lado, é sis-
tematicamente proposto para utilização das pessoas e dos envolvidos
que o projetam. Eventualmente usuários podem ter um entendimento e
conhecimentos diferenciados, sobre os requisitos do software, por isso,
existe a necessidade de poder atender aos diferentes usuários por meio
da transcrição detalhada das funcionalidades do software, ou seja, ter
uma documentação esclarecida e objetiva, com informações com intuito
de que todos os recursos sejam explorados de modo eficiente.
Por outro lado, o produto de software é desenvolvido para aten-
der uma solicitação específica de um cliente para o mercado, podendo
ter características genéricas onde é criado e vendido no mercado, para
qualquer cliente, ou ser personalizado em que o controle será realiza-
do pela organização que está adquirindo o software.
Outro fator importante nesta conceituação do software para
produto é primar por realizar testes, devido este, ser um fator de grande
importância para prever, sanar e corrigir as possíveis falhas que pos-
24
sam aparecer. Em síntese, um programa criado a fim de resolver algum
problema e um produto de software designado a resolver o mesmo pro-
blema, sendo assim, duas coisas completamente diferentes.
Modelos de ciclo de vida ou modelos de processo

Compreende o objetivo do modelo de ciclo de vida como o ato
de definir o processo e ciclo de vida, identificando e definindo suas fa-
ses e modelos. Para assim, analisar se no resultado prático gera aper-
feiçoamento da qualidade na produção de software.
Na prática, quando está decidindo um processo e escolhen-
do também um modelo ciclo de vida. Isto é uma abstração, representa
numa estrutura como guia para o processo, incluindo tarefas, ordem
prioridade entre elas, oferecendo opção, artefatos solicitados e produ-
zidos. De modo genérico, os ciclos de vida englobam as fases abaixo:
• Planejamento: proporciona uma estrutura que permite ao ge-
rente estipular tempo, custo, recursos, definir escopo do processo, de-
terminar um plano do projeto a ser seguido. Esta atividade é de respon-
sabilidade do gerente do projeto. Como também é importante a partir do
avanço do projeto, o planejamento ser adequado e atualizado.
• Análise e especificação de requisitos: esta fase se trata do

início e é super importante, pois, é a etapa de levantamento de requi-
sito, em que deve ser entendidos as funcionalidades, o problema e o
comportamento do software a ser desenvolvido, ou seja, descrever o
que software deve fazer. É imprescindível após feito o levantamento ser
realizada a documentação.
• Projeto: esta fase necessita da anterior, como base para agregar
os requisitos tecnológicos com que são vitais para o sistema. Necessita
ter uma plataforma de implementação definida e está relacionada a duas
fases, projeto da arquitetura do sistema e projeto planejado.
• Implementação: nesta fase trata-se de retirar o projeto do papel
e implementar o planejado por uma linguagem, ou seja, traduzir o projeto
para um meio passível de execução pela máquina.
• Testes: nesta fase compreende-se a realização de testes do sof-
tware para validar as funcionalidades desenvolvidas. Por meio de teste de
unidade, teste de integração e teste de sistema. Em que estes devem tes-
tar cada unidade de software desenvolvida e depois realizar a documenta-
ção dos testes. Como também realizar o teste do sistema completo.
• Entrega e implantação: nesta fase o software deve ser colocado
na produção. Deve ser realizado o treino dos usuários, como a configura-
ção do ambiente de produção e realizar a conversão da base se preciso.
25
• Manutenção: esta fase se trata de realizar alterações que po-
dem ser necessárias após a entrega do software. Podem ser solicita-
da algumas manutenções como corretivas para corrigir algo, evolutivas
referente a algumas funcionalidades novas a serem implementadas e
adaptativa para ajustar alguma funcionalidade do software. Estes são
exemplos de manutenção que possam ser requisitadas no processo do
software.
Com isto, temos que os modelos de processo ou ciclo de vida,
de modo genérico, envolvem as fases análise e especificação de requi-
sitos, projeto, implementação, testes, entrega e implantação. Porém, a
decisão de um modelo de processo é intensamente condicionada às
particularidades do projeto.
26
QUESTÕES DE CONCURSOS
QUESTÃO 1
Ano: 2020 Banca: Quadrix Órgão: Prefeitura de Canaã dos Carajás
- PA Prova: Prefeitura de Canaã dos Carajás Cargo: Analista Admi-
nistrativo - Administração
Acerca do programa de navegação Google Chrome, em sua versão
mais recente, e dos conceitos de organização e de gerenciamen-
to de arquivos e programas, julgue o item. Desde que se utilize o
programa correto, um arquivo PDF poderá ser dividido em dois ou
mais arquivos PDF.
( ) Certo
( ) Errado
QUESTÃO 2
Ano: 2020 Banca: IBADE Órgão: Prefeitura de Linhares - ES Pro-
vas: Prefeitura de Linhares – ES Órgão: Educador Físico
Alguns desenvolvedores de software oferecem cópias gratuitas,
que funcionam por um determinado período de tempo, para que
sejam testados. A esse tipo de cópia chamamos:

a) Data Base.
b) Trial.
c) Malware.
d) Freeware.
e) Shareware.
QUESTÃO 3
Ano: 2019 Banca: FCC Órgão: METRÔ-SP Prova: Analista Desen-
volvimento Gestão Júnior – Ciências da Computação
Considere as seguintes abordagens no contexto da Engenharia de
Software.
I. Intercala as atividades de especificação, desenvolvimento e va-
lidação. O sistema é desenvolvido como uma série de versões, de
maneira que cada versão adiciona funcionalidade à anterior.
II. Indivíduos e interações mais que processos e ferramentas; Sof-
tware em funcionamento mais que documentação abrangente; Co-
laboração com o cliente mais que negociação de contratos e Res-
ponder a mudanças mais que seguir um plano.
III. Tem por referência a matriz Fase versus Fluxos de Trabalho. São
alguns destes fluxos: Modelagem de negócios, Requisitos, Análise
e Projeto, Implementação, Teste e Implantação.
27
IV. Processo dirigido a planos em que se deve planejar e progra-
mar todas as atividades do processo antes de começar a trabalhar
nelas. Seus principais estágios são: Análise e definição de requisi-
tos; Projeto de sistema e de software; Implementação e teste unitá-
rio; Integração e teste de sistema e Operação e manutenção.
Correspondem, correta e respectivamente, às abordagens
a) Model Driven Architecture, Rational Unified Process, Desenvolvimen-
to Incremental e Modelo em Cascata.
b) Engenharia de Software Orientada a Reuso, Manifesto Ágil, Modelo
Espiral e Desenvolvimento Incremental.
c) Unified Modeling Language, Capability Maturity Model, Engenharia
de Software Orientada a Reuso e Modelo em Cascata.
d) Modelo Espiral, Manifesto Ágil, Model Driven Architecture e Capabi-
lity Maturity Model.
e) Desenvolvimento Incremental, Manifesto Ágil, Rational Unified Pro-
cess e Modelo em Cascata.
QUESTÃO 4
Ano: 2018 Banca: IBADE Órgão: IPM - JP Prova: Analista Previden-
ciário - Analista de Redes e Comunicação
No que diz respeito à Engenharia de Software, um modelo de pro-
cesso é visualizado como um ciclo de vida constituído da especifi-

cação, do desenvolvimento, da validação e da evolução, e as repre-
senta como fases do processo, cada uma separada das outras, tais
como especificação de requisitos, projeto de software, implemen-
tação e testes. Esse modelo de processo é denominado Modelo:
a) baseado em Prototipação.
b) baseado em Eventos.
c) em Espiral.
d) em Árvore.
e) em Cascata.
QUESTÃO 5
Ano: 2018 Banca: CESGRANRIO Órgão: Transpetro Prova: Analista
de Sistemas Júnior - SAP
A etapa do projeto unificado e a sua correspondente característica
são, respectivamente:
a) Concepção – levantamento de requisitos sistêmicos primários do ciclo
b) Construção – implementação dos elementos de maior risco e criticidade
c) Elaboração – mitigação dos problemas de alto risco do projeto
d) Incremento – diferenciação entre as entregas de duas etapas subse-
quentes
28
e) Transição – geração de um subconjunto executável do produto final
QUESTÃO DISSERTATIVA – DISSERTANDO A UNIDADE
Disserte sobre a importância da Engenharia do Software no processo

de desenvolvimento de um software, utilize a figura 2 apresentada como
elemento base para sua resposta.
TREINO INÉDITO
Cada dia mais percebemos que são exigidos softwares mais robustos e
com alta performance, à medida que a tecnologia avança, vai crescen-
do a cobrança e a necessidade de software mais complexo. Entende-
mos que o surgimento da Engenharia de Software veio agregar valor e
contribuições ao processo de desenvolvimento do software.
Conhecemos alguns princípios que fazem parte da Engenharia de Sof-
tware, selecione qual assertiva apresenta alguns destes princípios:
a) Rigor, abstração e modularidade;
b) Abstração, ferramenta e antecipação de mudanças;
c) Rigor, abstração e método;
d) Processo, método e generalidade;

e) Ferramenta, rigor e separação de interesses.
NA MÍDIA
“PROFISSÃO DO FUTURO”
“De acordo com dados da Associação Brasileira das Empresas de Sof-
tware (ABES), o Brasil foi o 9° país do mundo em investimentos na área
de tecnologia de informação (TI) em 2017, com valores que giram em
torno de 38 bilhões de dólares. Os números mostram que o mercado de
tecnologia segue em alta e pode ser uma excelente opção para estu-
dantes que buscam profissões que serão cada vez mais importantes.”
A reportagem traz a importância do curso de nesta área e a necessida-
de do mercado destes profissionais. Ressaltando que o engenheiro de
software pode atuar na criação de aplicativos e sistemas e na gestão
em todas as etapas do processo de desenvolvimento, garantindo a qua-
lidade do software a ser idealizado.
Fonte: (Portal G1)
Data: 29/11/2018
Leia a notícia na íntegra: <https://g1.globo.com/pr/parana/especial-pu-
blicitario/puc-pr/profissionais-do-amanha/noticia/2018/11/29/profissao-
-do-futuro.ghtml> Disponivel:11 de Abril de 2020
29
NA PRÁTICA
Lendo o artigo cujo o tema é:” Uma Proposta para o Ensino de Engenha-
ria de Software a partir da Resolução de Problemas”, o estudo trata de
analisar como o mercado de trabalho requer profissionais que demons-
trem, além de conhecimento específico, habilidades como proatividade,
iniciativa, capacidade de autoaprendizagem e trabalho em equipe. Mos-
trando a contribuição das características, o curso de Engenharia de Sof-
tware (ES) da Instituição X, que foi idealizado com base na abordagem
de ensino-aprendizagem ABP (Aprendizagem Baseada em Problemas).
Acesse o link: <https://www.br-ie.org/pub/index.php/rbie/article/
view/1391>
PARA SABER MAIS

Filmes sobre o assunto: Piratas da informática -1999
MinorityReport - A Nova Lei-2002
Acesse os links:
Disponível em:<https://youtu.be/WdjhXIABM6I>
Disponível em:<https://youtu.be/QH-6UImAP7c>
30
MODELOS DE PROCESSOS

DE DESENVOLVIMENTO DE SOFTWARE
Conforme foi descrito no capítulo anterior, a importância da En-
genharia de Software e sua definição que é composta por camadas de
métodos, ferramentas e processo, vimos também a definição do modelo
ciclo de vida ou de processo, que trata de definir e identificar fases e
modelos, avaliando, gerando na prática contribuição para produzir com
qualidade software.
No presente capítulo, iremos iniciar abordando sobre a concei-
tuação do software como produto, trazendo os fatores que contribuem
para o seu bom desenvolvimento de atender às requisições solicitadas
pelos clientes.
Ainda serão vistos os modelos do processo de software, tra-
zendo um breve histórico da evolução e características de cada modelo.
Iremos abordar sobre os modelos sequencial, evolutivo e incremental,
apresentando os exemplos de cada um com suas devidas atividades.
Dessa forma, ainda será abordado também como trabalha e
as características dos processos ágeis, com detalhamento do processo
XP, como a descrição sobre o processo unificado e MDA. E, por fim, a
conceituação de software como produto.
31
HISTÓRICO DE EVOLUÇÃO DOS MODELOS DE PROCESSOS DE
SOFTWARE
Após entendermos a importância do software e o que conceitua

como produto de software vamos relembrar o que entendermos sobre o
modelo de ciclo de vida ou modelo de processo para o desenvolvimento
do software. Vimos no capítulo anterior que o modelo de processo com-
preende uma abstração de uma estrutura de processo, contendo ca-
racterísticas de algumas tarefas primordiais, ou seja, é um conjunto de
tarefas onde o intuito é o desenvolvimento ou a evolução do software.
Saliente-se ainda que umas das primeiras decisões do projeto
é o modelo de processo de software, que precisa ser resolvido pelo en-
genheiro de software, uma vez que determina a abordagem sistemática
que será seguida para desenvolver um projeto de software.
Vimos ainda que modelos de processo ou ciclo de vida, de
modo genérico, envolvem as fases análise e especificação de requisi-
tos, projeto, implementação, testes, entrega e implantação.
Por isso, é importante conhecer e entender as características
e elementos de alguns modelos de processo, para assim, facilitar o pro-
cesso de tomada de decisão de qual modelo escolher. Vale ressaltar
que essa é uma das principais decisões para o projeto o software, deci-
dir o modelo adotado e quais abordagens se encaixam melhor. Inclusive
existe atributos que qualificam um bom software, como: facilidade de
manutenção, nível de confiança, eficiência e facilidade de uso.
Ademais, os principais modelos de processo de software po-
dem ser ajuntados em três categorias principais: modelos sequenciais,
modelos incrementais e modelos evolutivos. Nas seções abaixo serão
descritos esses modelos, com exemplificação de cada um.
Modelo sequencial
O modelo sequencial tem uma estrutura organizada no proces-
so em uma sequência linear de fases. Um exemplo de modelo sequen-
cial é o modelo cascata no ano de 1970, que foi proposto por Winston
Walker Royce, também conhecido como ciclo de vida clássico.
Vale expor que este é um dos mais antigos e que foi bastante
utilizado na Engenharia de Software, tendo como característica uma
estrutura sistemática e sequencial. Em que uma tarefa só é começada
quando a anterior for completada na sua totalidade, neste modelo itera-
ções no ciclo não são previstas. (CORTÉS,2013)
A figura abaixo representa como funciona o modelo cascata,
onde cada fase é realizada sequencialmente.
32
Figura 3 - Modelo cascata
FONTE: (PRESSUMAN, 2011)
O modelo cascata tem pouca complexidade e é simples, de-

vido não ser disponível realizar tarefas em paralelo. As tarefas neste

modelo são feitas em sequência e não proporciona retorno para mudar
alguma tarefa feita anteriormente, e a documentação só é realizada no
final do processo. Uma grande desvantagem deste modelo é que requer
um maior custo nas correções das especificações nas fases como teste
e implantação.
Uma importância deste modelo na Engenharia de Software é
devido a existir muitos outros modelos mais complexos que são, de fato,
alterações do modelo cascata, incorporando laços de feedback.
Outro exemplo de modelo sequencial é o Modelo em V, que é
uma modificação do modelo em cascata, que busca ressaltar e aproxi-
mar a relação entre as tarefas de teste e as demais fases do processo,
como mostra a figura abaixo, que ilustra a representação do modelo V.
33
Figura 4 - Modelo V
Análise e Especificação Teste de Aceitação
de Requisitos (Entrega e Implantação)
Projeto de Teste de
Arquitetura Sistema
Teste de
Projeto de Detalhado
Unidade e
Integração
Implementação
FONTE: (FALBO, 2005)
Assim vemos na figura 4 do modelo em V acima, a represen-

tação em que cada fase do lado esquerdo gera um plano de teste a ser
executado no lado direito. Caso
exista um problema em alguma tarefa de teste, podem precisar
ser executadas novamente para corrigir ou aperfeiçoar o problema.
Conforme acontece no modelo em cascata, o cliente só recebe

a primeira versão do software no final do ciclo, porém, uma vantagem
do modelo em v é com relação ao risco que é menor, por conta do
planejamento previsto dos testes nas fases de análise e projeto
Modelo incremental
Este modelo foi idealizado por Mills em 1980 e trabalha divi-
dindo o desenvolvimento do software em módulos, em que cada um é
desenvolvido conforme as fases do modelo cascata. Assim, tem como
uma característica oferecer versões do código a cada incremento, con-
tudo, precisa atenção no planejamento.
Em suma, este modelo usa os elementos do Modelo em Cas-
cata executando de modo iterativo, isso significa que de modo gradativo
acontecem incrementos em que ocorrem consecutivos aprimoramentos
de cada iteração (PRESSMAN, 2006).
Temos assim o modo incremental, que é uma boa opção para
sistemas de grande porte, pois, oferece uma versão do software, por
partes, mostrando resultados importantes já no início do projeto. Abaixo
é apresentada a figura 5, que ilustra este modelo.
34
Figura 5 : Modelo incremental
LEVANTAMENTO DE PLANEJAMENTO DE PROJETO

REQUISITOS
INCREMENTOS
DESENVOLVER VALIDAR INTEGRAR VALIDAR

INCREMENTOS INCREMENTO SISTEMA
INCREMENTO
FONTE: (CORTÉS, 2013)
Contextualizando, este modelo na prática é como se o siste-

ma constituísse uma divisão em subsistemas, e para cada subsistema
existisse o aproveitamento de um ciclo em cascata. Logo, em vez de
realizar uma avaliação do sistema completo, é realizada uma análise de
somente de uma parte do sistema; entretanto, esta análise carece estar
finalizada para que seja começado o projeto. Este modelo estabelece a
revisão do cliente.
Vale ressaltar algumas vantagens do modelo incremental,

como: oferecer menor custo, apresenta um tempo de entrega de versão
menor; apresenta menor risco devido a alteração estar sempre sendo
entregue versões menores. Contudo, tem algumas desvantagens como,
requer um gerência de projeto com uma maior complexidade.
Modelos evolutivos ou evolucionários

Devido à necessidade de atender aos avanços do mercado,
sempre exigindo um aperfeiçoamento de melhorias para desenvolver
o software, como a pressão dos clientes com relação aos prazos de
entrega e exigências que sempre vão requisitando prazos mais curtos
para receber o produto.
Desse modo, surge a necessidade de ter um modelo que pos-
sibilitasse suprir esta necessidade, permitindo assim no seu processo a
entrega de uma versão restrita, que vai evoluindo ao longo do tempo, ou
seja, o cliente vai recebendo as versões e o produto vai evoluindo com
o tempo e o cliente vai vendo se este vai suprindo seus objetivos, isto
foi um modo encontrado para aliviar a tensão e cobrança do mercado.
Contudo, surgiu o modelo evolutivo, justamente formado por
duas fases, uma corresponde à parte de exploração e a outra seguida
da parte de desenvolvimento evolutivo. Em que o período de exploração
35
gera os requisitos que o sistema necessita dar suporte, e o desenvolvi-
mento evolutivo é referente a um conjunto de etapas, em que cada uma
é designada a elaborar determinadas funcionalidades do sistema.
Uma importante característica que merece ser destacada do

modelo evolucionário é dele ser iterativo, permitindo elaborar versões
do software, gradativamente mais completa, ao longo do tempo.
Assim, seguem abaixo exemplos deste modelo: o espiral e a

prototipagem.
Modelo Espiral
Podemos citar como um exemplo deste modelo é o espiral,
que foi elaborado por Barry Boehm, e este trata-se de conectar a carac-
terística iterativa da prototipação com os elementos sistemáticos e de
controle do modelo cascata. Em que acaba por fomentar um potencial

para criar versões de software de modo mais rápido e completo.
Em suma, a principal característica desse modelo é justamente
esse benefício de nas primeiras iterações, gerar uma versão que trata
de ser um modelo ou um protótipo, outro fator é que adiciona o ele-
mento análise de risco ao modelo. Logo nas próximas iterações, são
desenvolvidas versões gradativamente mais completas, passando pelo
processo de engenharia. Porém, é interessante destacar que, a cada
ciclo, o planejamento precisa ser examinado, levando consideração o
feedback do cliente, acertando até mesmo a quantidade de iterações
planejadas
Com isto temos, a figura 6 abaixo, que ilustra como é represen-
tado este modelo com o formato de espiral, iniciando no sentido horário
pelo seu centro. Desta forma, podemos observar também o nome das
fases do projeto, que são representadas por cada iteração na espiral.
36
Figura 6: Modelo Espiral

As seguintes atividades podem compor o modelo espiral:

• Definição e especificação: nesta etapa é elaborado um pla-
no de gerenciamento fundamentado na descrição dos objetivos e nas
exceções sobre o processo e o produto, fazendo um levantamento dos
riscos relacionados.
• Análise: nesta etapa, baseada nos riscos levantados, é feita
uma análise objetivando a definição de medidas para evitar e reduzir
ocorrências e antecipar o uso de protótipos para contribuir com a dimi-
nuição de riscos.
• Construção: nesta etapa o produto é desenvolvido.
• Planejamento: nesta etapa é analisado o projeto e idealizado
o planejamento da seguinte iteração na espiral.
37
Modelo de Prototipagem
Modelo de Prototipagem é baseado no desenvolvimento do
software acelerado de uma versão antecipada do software, ou protóti-
po, desenvolvido, principalmente, para ajudar a compreender melhor o
problema e a necessidade do cliente.
Usualmente, o protótipo auxilia no processo de levantamento
de requisitos de software, principalmente com relação quando cliente já
tem especificado todos objetivos gerais do software.
Assim, temos este modelo iniciando com o cliente o ciclo de
prototipagem, realizando o levantamento dos requisitos gerais do sis-
tema, elaborado com isto o projeto rápido. Uma característica para ser
citada é que o protótipo não fundamentalmente será responsável por
modelar todas as funções do sistema, pois, esta seleção de funcionali-
dades precisa ser estipulada pelos clientes.
Por mais que o principal objetivo do protótipo consista em com-
preender os requisitos do usuário, este ainda pode ser utilizado para
fomentar teste e evidenciar definições do software. Podemos ter por
exemplo, um protótipo que tenha a função de gerar teste para alteração
ou ajuste de uma determinada tecnologia e a requisição do projeto.
Assim, o processo da prototipação parte da comunicação entre
os clientes e envolvidos no projeto, definindo objetivos e especificando
quais dos requisitos levantados precisam ser organizados e de concei-

tos mais gerais.
Nisto uma iteração de prototipação é organizada de modo rá-
pido e ocorre a modelagem para fazer um projeto rápido. Por sua vez,
este tem características de mostrar ao cliente uma visão geral dos as-
pectos do software para os usuários finais, exemplo: design interface
de usuário ou desenho de uma tela, um software contendo algumas
funcionalidades do sistema.
38
Figura 7: Modelo de prototipagem
Dessa forma, como é observado, na figura 7, no modelo de

prototipagem temos a representação do modelo em que se inicia com
levantamento para obter requisitos e, partir disto, parte para execução
do ciclo de prototipagem, que vai alimentando as próximas fases no
processo de desenvolvimento para construir produto. Encerrando assim
o ciclo com a fase de prototipagem e trazendo as informações importan-
tes, o protótipo necessita ser desconsiderado.
Alguns problemas que podem ter com a prototipação é que
devido serem entregues protótipos, ocorre de não considerar a quali-
dade do software e a manutenção ao longo prazo. Outro problema é a
escolha de um sistema operacional ou linguagem de programação ina-
dequados, podem ser usados apenas por estarem disponíveis ou serem
conhecidos; assim pode gerar escolha de algoritmo ineficaz.
Contudo, a prototipação oferece grande contribuição no pro-
cesso de desenvolvimento, pois, se forem determinadas bem as regras
no início do modelo, isso contribui de modo eficiente como elemento
para levantar requisitos. Assim, será rejeitada alguma parte do modelo
e, no final, o software é arquitetado primando pela qualidade.
39
PROCESSOS ÁGEIS
Os métodos ágeis foram idealizados para substituir processos

mais difíceis que não trabalham para projetos menores ou de baixa
complexidade. Outro objetivo para criação deles foi abordar o desenvol-
vimento de aplicações de negócios, em que, os requisitos de sistema
são alterados de modo rápido durante o processo de desenvolvimento.
É importante salientar que os métodos ágeis têm sua ênfase

em produzir software com entregas rápidas para o cliente. Fundamenta-
do nos métodos iterativo e incremental a metodologia ágil.
Este modelo de processo, na maioria das vezes, é denominado

como “ágil”, por focar em ser flexível e adaptável. Podemos citar alguns
elementos dos métodos ágeis como: desenvolvimento do cliente, entre-
ga do software incremental, valorizar os envolvidos sobre os processos,

aceitar a alteração e dar suporte à simplicidade do código.
Os métodos ágeis são formados por princípios, valores e prá-
ticas básicas.
A Aliança Ágil determinou um manifesto tendo doze princípios aos quais as

metodologias ágeis de desenvolvimento de software devem se adequar. Os
doze princípios do manifesto são (AMBLER, 2004)
1. Nossa maior prioridade é satisfazer ao cliente mediante entregas de sof-
tware de valor em tempo hábil e continuamente.
2. Receber bem mudanças de requisitos, mesmo em uma fase mais avan-
çada no
desenvolvimento.
3. Entregar software em funcionamento com frequência de algumas sema-
nas a alguns meses, de preferência na menor escala de tempo.
4. As equipes de negócios e de desenvolvimento devem trabalhar juntas dia-
riamente
durante o tempo todo.
5.Construa projetos ao redor de indivíduos motivados. Dê-lhes o ambiente e
o apoio de que eles precisam e confie neles para realizar o trabalho.
6. O método mais eficiente de levar informações para uma equipe de desen-
volvimento e fazê-las circular é a conversa cara a cara.
7. Ter o software funcionando é a principal medida de progresso.
8. Processos ágeis promovem o desenvolvimento sustentável. Os patroci-
40
nadores,
desenvolvedores e usuários deveriam ser capazes de manter um ritmo cons-
tante
indefinidamente.
9. Atenção contínua a excelência técnica e a um bom projeto aumentam a
agilidade.
10. Simplicidade é essencial.
11. As melhores arquiteturas, requisitos e projetos provêm de equipes
12. A intervalos regulares, a equipe se avalia para ver como tornar-se mais
eficiente, então sintoniza e ajusta seu comportamento (AMBLER, 2004, p.
38).
Os valores dos métodos ágeis são: comunicação, simplicidade,

retorno (feedback), coragem e humildade. Já as práticas são compostas
pelas descritas abaixo:
• Modelagem iterativa e incremental: aplicação dos artefatos
corretos, criar diferentes modelos em paralelo, integrando em outro ar-
tefato, modelando de modo incremental;
• Trabalho de equipe: modelar com outras pessoas, organizar
uma participação ativa dos clientes, promover a posse coletiva, disponi-
bilizar os modelos publicamente;
• Simplicidade: criar conteúdo simples, mostrar modelos de

modo simples e como também ferramentas mais simples
• Validação: considerar a testabilidade, comprovar o código.
Alguns exemplos de métodos ágeis são XP (eXtreme Progra-
ming) e Scrum. Neste capitulo destacaremos o método XP.
XP - eXtreme Programing
O Extreme Programming (XP) é um modelo de desenvolvimen-
to de software ágil, idealizado em 1996, por Kent Bech, no Departa-
mento de Computação da montadora de carros Daimler Crysler. Este
modelo é formado por cinco valores que servem como base de trabalho
de seus métodos, esses são comunicação, simplicidade, retorno, co-
ragem e respeito. Esses valores são utilizados como uma direção das
atividades, ações e tarefas próprias do processo XP.
Comunicação: XP tem ênfase em construir uma compreensão
entre os envolvidos do problema, com a utilização mínima de documen-
tação formal e com a utilização máxima de interação entre os envolvi-
dos no projeto. Ocorre práticas de XP como programação em pares,
testes e comunicação.
Simplicidade: XP tem foco em optar pelo mais simples para
solucionar os problemas e que possibilite que os custos de alteração
41
sejam baixos. E esse processo tem intuito de evitar a construção pre-
matura de funcionalidade.
Feedback: trata de um valor do processo XP que é importante
porque oferece um retorno para os programadores sobre o projeto, até
mesmo, para dar ideia da criação dos testes. Para os clientes, oferece
retorno dos testes criados e das funcionalidades como todo. Dessa for-
ma assim, ajuda aos envolvidos no projeto, a entender mais o sistema
e corrigir quando necessário, promovendo um aperfeiçoamento dos sis-
temas.
Coragem: trata de um valor do processo XP, que é de suma
importância no processo XP, pois, é necessário que os programadores
tenham coragem para poder fazer com que o projeto atenda às neces-
sidades do cliente do melhor modo. Também possibilita o programador
não ter receio, em alterar o código quando preciso ou até mesmo ter
que recomeçar do zero.
O método XP também determina um conjunto de princípios que
contribuem na seleção de opções de solucionar problemas que surjam
no decorrer do projeto. Os princípios fundamentais são: feedback rápi-
do, assumir simplicidade, mudança incremental, abraçando mudanças
e trabalho de qualidade.
• Feedback rápido: consiste da ideia de que no XP os envolvidos
no projeto estejam sempre se comunicando sobre tudo que esteja

ocorrendo no decorrer do projeto, para que caso haja alguma dúvida
ou problema propiciem que ocorra rapidamente o feedback para sanar
essas eventualidades, com ações de contingência adequadas.
• Assumir simplicidade: ter ações simples no desenvolvimen-
to do projeto, desde de implementação, testes e refatoração. Acreditar
também na sua habilidade que se no futuro algo mais complexo for so-
licitado poderá ser adicionado.
• Mudança incremental: o princípio da metodologia XP trabalha
partindo do pressuposto que as mudanças precisam ser incrementais e
realizadas gradativamente.
• Abraçando mudanças: o princípio da metodologia XP que
busca, sempre facilitar o ato de adicionar, mudanças por meio da utili-
zação dos vários princípios e práticas.
• Trabalho de qualidade: princípio da metodologia que é obriga-
tório a qualidade, no sentindo de atender às solicitações dos clientes e
promover com que todos os testes estejam funcionado.
• Desta forma, para aplicar os valores e princípios no decorrer
do desenvolvimento de software, o XP estabelece uma série de práticas
como:
• Jogo de Planeamento (Planning Game): o desenvolvimento é
42
realizado em iterações semanais. Em que, no início da semana existe
uma reunião com os todos envolvidos no projeto para entender a prio-
ridade das funcionalidades e os desenvolvedores poderem estimar o
tempo. Vale ressaltar que no fim de cada semana é entregue ao cliente
novas funcionalidades, que já foram testadas, prontas para serem colo-
cadas em produção. O cliente é peça fundamental neste processo, pois,
ele sempre está ciente do que está ocorrendo no projeto.
• Pequenas Versões (Small Releases): neste processo são dis-
ponibilizadas pequenas versões das funcionalidades do projeto, contri-
buindo muito no processo do cliente validar se o projeto está atendendo
suas necessidades.
• Metáfora (Metaphor): neste princípio busca por contribuir na
comunicação com o cliente e os programadores dando uma visão geral
do sistema que gera uma melhor compreensão.
• Programação em par: neste princípio incentivam a colabora-
ção entre os programadores mais experientes com os menos, a traba-
lharem em duplas por computador.
• Reuniões em pé (Stand-up Meeting): neste princípio incentiva
reuniões em pé e rápidas, somente trabalhando com tarefas concluídas
e a serem concluídas pela equipe.
• Posse Coletiva (Collective Ownership): Objetivo neste princí-

pio é promover que a equipe possa conhecer toda as partes do projeto.
E ninguém precisa ter permissão, todos podem alterar.
• Ritmo Sustentável (Sustainable Pace): neste princípio incen-
tiva a trabalhar no ritmo estipulado (40 horas/semana, 8 horas/dia), sem
usar de horas extras, motivando a produtividade para a execução do
projeto.
• Refatoração (Refactoring): este processo permite a melhoria
constante do código de programação sem mudar funcionalidade.
Ainda sobre o processo XP abarca determinadas fases durante
o seu ciclo de vida. Fases estas que são compostas de diversas tarefas
que são executadas como: exploração, planejamento inicial, iterações
do release, produção, manutenção e morte.
• Fase de exploração: é referente ao início e vem antes da
construção do sistema.
• Fase das iterações: é referente à produção dos releases em
que são escritos os casos de teste funcionais e de unidade. Ainda são
escritos os casos de testes, projeto e refatoramento; codificação, reali-
zação dos testes e integração. A partir da entrega da primeira release
poderá determinar como sucederá as próximas e até diminuindo o tem-
po de entrega. Vale ressaltar que release é algo que é implantado no
cliente, ou seja, está pronto para ser usado.
43
• Fase de produção: é referente em que cada release seguinte
do sistema, após ser construído, é posto para ser executado, simulando
o ambiente de produção para poder avaliar a performance.
• Fase de manutenção: é referente estar sempre produzindo
novas funcionalidades, preparando sempre o sistema para receber no-
vos códigos, como viabilizando correta quando necessária.
• Fase de morte: é referente à finalização do projeto XP, que
pode ser finalizado por motivos, tais como não atender as expectativas
do cliente, ou por não ser mais viável no âmbito econômico.
Outro elemento importante no processo XP são os papéis e
responsabilidades do Extreme Programming, apresentados a seguir:
• Gestor: esse tem o papel de ser responsável por interagir com
os envolvidos do projeto e tomar decisão.
• Consultor: este se refere a um membro externo da equipe e
que tem qualificação técnica específica para um projeto determinado.
• Desenvolvedor: este se refere ao papel de quem implementa
os programas, prepara os testes e o código bem estruturado, de modo
coeso e simples. Como também tem a habilidade boa de comunicação.
• Cliente: este é referente a repassar as solicitações desejadas,
como os requisitos funcionais e validá-las. Este que determina a priori-
dade e obrigatoriedade dos requisitos para serem inseridos no projeto.
• Testador: este é responsável por ajudar o cliente a elaborar os

testes dos requisitos funcionais, por executar e informar aos envolvidos
os resultados dos testes.
• Monitor: este é responsável por analisar a concordância das
estimativas realizadas pelos envolvidos no projeto. Também é respon-
sável por acompanhar o avanço das iterações e analisar se as metas
estão coerentes, conforme limitações de recursos e tempo.
• Treinador: este tem o papel de verificar se o processo contém
integridade. A pessoa que assume este papel é uma que tem mais expe-
riência em XP devido ser preciso conduzir todos os dados dos projetos.
Processo unificado
Este Processo Unificado (PU) é um modelo de ciclo de vida
evolucionário de desenvolvimento de software que engloba os proces-
sos iterativo e incremental para a criação de software. Este também
pode ser compreendido como um framework que pode ser persona-
lizado conforme as particularidades e recursos disponíveis para cada
projeto (SCOTT, 2003).
Nisto o PU condiz a um bloco de tarefas precisas para modificar
os requisitos do usuário de um software. Vale salientar que o processo
44
unificado é formado por três definições seguintes: dirigido pelo caso de
uso; centralizar na arquitetura; iterativo e incremental. O Processo Uni-
ficado trabalha a criação do software no decorrer do tempo, de modo
iterativo e incremental, em que ao finalizar, cada iteração é suscitada
uma versão nova do produto. Este usa Linguagem de Modelagem Uni-
ficada (Unified Modeling Language – UML) na organização de todos os
artefatos do sistema.
Este processo é formado pelos 4PS: pessoa, projeto, produto
e processo:
• Pessoa: referente a quem gerência, desenvolve, financia, e
realiza os teste de software.
• Projeto: referente as pessoas que irão trabalhar no projeto e
com os artefatos (qualquer tipo de informação criado por uma pessoa,
exemplo diagrama UML, texto e modelos).
• Produto: referente ao código fonte, classes, diagramas.
• Processo: referente a descrever esses pontos: de quem pos-
sui o papel, quem está fazendo o quê, como será realizada a atividade
e quando será feito.
Abaixo temos as fases que compreendem esse processo:
(PRESSMAN,2010)
• Fase de concepção: esta fase é relacionada com a tarefa

de comunicação estabelecida com o cliente, como a de planejamento.
Assim, investiga as necessidades de negócio para atender e arquitetar
o software. Desenvolvendo um planejamento iterativo e incremental do
projeto.
Fase de elaboração: esta fase é relacionada à elaboração,
aprimora e amplia os casos práticos preliminares, elaborados como ele-
mento da fase de concepção, e expande a representação da arquite-
tura, contendo cinco visões diversas do software como modelo: caso
prático, requisitos, projeto, implementação e emprego.
• Fase de construção: Essa fase é responsável por receber
elementos de software; esses elementos são responsáveis por trazer
operação para os usuários finais.
• A fase de transição: compreende as tarefas de construção
gerais como entrega e feedback. Assim, esta fase é responsável por
entregar o software aos usuários finais para testes beta e o feedback
dos usuários descreve distorções e alterações precisas.
• Fase de produção: esta fase é referente por gerenciar a uti-
lização do software, trazendo apoio para infraestrutura operacional,
abrangendo e realização, da avaliação dos relatórios de erros e a requi-
sições de alterações.
45
Model Driven Architecture (MDA)
Partindo da compreensão Model Driven Development (MDD)
é uma subárea inserida na Engenharia de Software que incentiva a
utilização de modelos como artefatos importantes no processo de
desenvolvimento de software. Tendo como intuito de obter a proposta
de MDD, apareceram vários padrões, ferramentas e abordagens (Kle-
ppe, 2003).
Dentre elas a mais conhecida é Model Driven Architecture
(MDA) que é denominada como um framework conceituado pela Object
Management Group (OMG), esta arquitetura contém suas definições
básicas com intuito explorar a hipótese fundamental sobre o proces-
so de desenvolvimento de software orientado a modelos. Trabalhando
com a ênfase maior a questão da modificação de modelos por meio de
metamodelos. Esta técnica promove a automação do processo ao se
utilizar tecnologias de transformações modelo-modelo. Em suma, abai-
xo é apresentando definições básicas para facilitar o entendimento da
arquitetura orientada a modelos, o padrão MDA: (Object Management
Group, 2003)
• Metamodelos – se refere a apresentar como podem ser cria-
dos os modelos. É semelhante a uma gramática que determina uma
linguagem de programação.
• Modelos: representam as instâncias dos metamodelos;
• Dirigido a Modelos MDA: isto implica em afirmar que é dire-
cionado a modelos, com objetivo de usar os modelos para guiar o an-
damento do entendimento, projeto, construção, distribuição, operação,
manutenção e modificação.
• Arquitetura: é a representação do que compõe, juntamente
com os conectores, como também, as regras de interação dessas par-
tes usando os conectores.
• Transformações: refere-se a uma junção de regras que deter-
mina um modelo de entrada que pode ser modificado em outro modelo
de saída.
• Ponto de vista: refere-se a uma técnica de abstração, usada
num conjunto selecionado de conceitos arquiteturais e regras de es-
truturação que visam focar ou representar um aspecto (característica)
dentro desse sistema. O termo abstração é usado para significar o pro-
cesso de suprimir (esconder) um detalhe selecionado para estabelecer
um modelo simplificado.
• Plataforma: uma plataforma é um conjunto de subsistemas e
tecnologias que provê um conjunto coerente de funcionalidades através
de interfaces e padrões de uso especificado, que qualquer aplicação
46
(sistema) suportada por essa plataforma pode usar, sem ter que conhe-
cer os detalhes de como essa funcionalidade provida pela plataforma é
implementada.
• Modelos MDA: refere-se a dividir os vários níveis de abstra-
ção de um software e incentivar contribuições recomendados pelo pro-
cesso de desenvolvimento para dirigir os modelos. A arquitetura MDA
aborda modelos distribuídos em quatro camadas a seguir:
• Computational Independent Model (CIM): Este modelo da ca-
mada está relacionado à visão geral do sistema sem focar na compu-
tação, também é denominado modelo negócio. Assim, esse modelo é
adquirido no momento da documentação e de especificar os requisitos.
• Platform Independent Model (PIM): Este modelo é composto
pelo requisito computacional do sistema, porém, é independe da plata-
forma adotada na implementação.
• Platform Specific Model (PSM): Este modelo que adicionado
ao PIM e detalha implementação da plataforma, na qual o sistema será
executado. Com ele também é permitida a modificação do mesmo no
código da aplicação.
• Código – Este é a sintaxe real, que é trazida a partir do PSM.
Porém, permite também gerar o código por meio de um PIM, mesmo
com a complexidade alta relacionada à transformação.

Modelo axiomático
Esta teoria de Projeto Axiomático passou a existir como um
processo para projeto de produtos, sendo inicialmente utilizada em ou-
tras áreas da engenharia. Porém, este processo é fundamentando em
definições que relacionam a independência entre os requisitos funcio-
nais do projeto e na diminuição do conteúdo de informação do projeto
(SUH, 1990).
Para entender este modelo precisamos partir da definição de
axioma, que é oriunda da matemática, que descreve que estas são ver-
dades que não podem ser derivadas, contudo, significa que não existem
contra exemplos e exceções (SUH, 1990). Para outras áreas da ciência
os axiomas apresentam princípios fundamentais, como por exemplo, na
área da física as leis da mecânica de Newton.
O modelo axiomático foi aplicado no desenvolvimento de sof-
tware e tem como objetivo melhorar a qualidade do processo de de-
senvolvimento, promover garantia a qualidade do produto desenvolvido.
Além do que, este modelo pode ser aplicado em praticamente qualquer
área da ciência, até mesmo na especificação de projetos de software.
Bem como este modelo trabalha com dois axiomas, em que o
47
primeiro axioma é denominado axioma da independência, isto implica
que a independência dos requisitos funcionais precisa sempre ser sus-
tentada. O segundo denominado de axioma da informação, este implica
que entre aqueles projetos que satisfaçam o primeiro axioma, o melhor
será aquele que tiver o menor conteúdo de informação. (SUH, 2001)
Vale ressaltar que projeto axiomático é aplicado de modo prin-

cipal na relação entre os domínios funcional e físico, devido à tarefa do
projeto em si, ser representada pelo mapeamento de requisitos funcio-
nais para parâmetros.
Suh (2001), relata que o projeto axiomático aperfeiçoa a ca-

pacidade criadora do projetista, por conta de exigir uma definição es-
clarecida dos objetivos do projeto e disponibiliza critérios para que as
más ideias sejam extinguidas. Assim, este modelo define quatro domí-
nios fundamentais, que colaboram no desenvolvimento de um projeto :
Domínio do Cliente, Domínio Funcional, Domínio Físico e Domínio de

Processo. Estes domínios demarcam quatro tipos diferentes de tarefas
do projeto que se relacionam.
• Domínio do Cliente: refere-se às necessidades do cliente.
• Domínio Funcional: refere-se às necessidades que são ex-
planadas e descridas como em requisitos funcionais do produto. Para
gerar a satisfação, os requisitos funcionais são idealizados os parâme-
tros de projeto.
• Domínio Físico: refere-se a desenvolver o produto especifi-
cado pelos parâmetros de projeto, por meio do processo caracterizado
pelas variáveis de processo, pertencentes ao Domínio de Processo.
48
QUESTÃO 1
Ano: 2020 Banca: IBFC Órgão: TRE-PA Prova: Analista Judiciário -
Análise de Sistemas
Para aplicar valores e princípios do XP (Extreme Programming),
durante os processos e práticas ágeis de desenvolvimento de sof-
tware, se propõe uma série específica de práticas. Assinale a alter-
nativa que apresenta algumas dessas “boas práticas” utilizadas
tradicionalmente em projetos, usando XP.
a) Reformation – Pair Programming - PlayStation Game
b) Refactoring – Pair Programming - Planning Game
c) Reformation – Pair Production - Planning Game
d) Refactoring – Pair Production - PlayStation Game
QUESTÃO 2
Ano: 2019 Banca: INSTITUTO AOCP Órgão: EMPREL Prova: Ana-
lista de Sistemas
Em se tratando de desenvolvimento de software, o termo qualida-
de é bastante subjetivo. Entretanto, no desenvolvimento ágil, é cla-

ro o conceito de qualidade. Sabendo disso, assinale a alternativa
que apresenta corretamente o conceito de qualidade no desenvol-
vimento ágil.
a) Envolve a documentação do processo e o estabelecimento de práti-
cas para entregar ao cliente um produto de qualidade.
b) Cumpre os critérios sistêmicos estabelecidos em acordo com o clien-
te para que os requisitos também sejam cumpridos.
c) Tem como objetivo gerar manuais e código claro por meio de uma
equipe especializada no processo.
d) Cumpre os requisitos para o cliente com uma documentação comple-
ta do produto desenvolvido.
e) Significa que a qualidade do código e as práticas são utilizadas para
garantir um código de alta qualidade.
QUESTÃO 3
Ano: 2019 Banca: INSTITUTO AOCP Órgão: EMPREL Prova: Ana-
lista de Sistemas
Assinale a alternativa que apresenta uma das características do
Scrum referente ao Scrum Team (Time Scrum).
a) O time valida com o cliente as características (features) ou requisitos
do produto.
49
b) Um líder determina como é a distribuição das tarefas e a programa-
ção aos pares.
c) O líder do time Scrum deve priorizar as funcionalidades que serão
desenvolvidas.
d) É auto-organizável e não ultrapassa sete pessoas em sua composi-
ção.
e) Reuniões diárias são realizadas para possibilitar a interatividade das
tarefas.
QUESTÃO 4
Ano: 2020 Banca: FADESP Órgão: UEPA Prova: Técnico de Infor-
mática
Um dos princípios do Manifesto Ágil é o de que os indivíduos e
interações são mais importantes que processos e ferramentas. Um
outro princípio é o de que
a) o usuário é a principal fonte de informação de requisitos de software.
b) os contratos são mais importantes que a colaboração com os clientes.
c) o software funcionando é mais importante do que a documentação
completa e detalhada.
d) seguir o plano inicial é mais importante que a adaptação a mudanças.
QUESTÃO 5
Ano: 2019 Banca: CS-UFG Órgão: UFG Prova: Técnico de Tecnolo-
gia da Informação
O desenvolvimento de software baseado em abordagem ágil esti-
mula
a) a produção de planos detalhados.
b) a realização de atividades de desenvolvimento em cada iteração.
c) a valorização da equipe de operação em detrimento daquela de de-
senvolvimento.
d) a aplicação de métodos formais de desenvolvimento de software
Os métodos ágeis são um modelo de processo de software em que é

formado por princípios e valores. Sendo assim, ante a temática propos-
ta, disserte resumidamente sobre alguns dos valores do modelo ágil XP.
TREINO INÉDITO
O modelo evolutivo ou também conhecido como evolucionário é forma-

do por duas fases, uma corresponde à parte de exploração e a outra
50
seguida da parte de desenvolvimento evolutivo.
Este modelo tem como objetivo trabalhar com produtos que permitam
evoluir ao longo do tempo. Marque a alternativa que descreve os mode-
los que são exemplos deste modelo descrito acima:
a) modelo espiral e prototipagem;
b) modelo cascata e modelo V;
c) modelo XP e modelo cascata;
d) modelo V e modelo espiral;
e) modelo de prototipagem e modelo XP.
NA MÍDIA
“5 erros que podem ser fatais na implementação de metodologias ágeis”

“Os CIOs já estão cientes dos diversos benefícios da metodologia agile,
mas existem alguns equívocos que podem estar atrapalhando os resul-
tados nas organizações. Pensando nisso, pedimos a alguns especialis-
tas na área para discutir os conceitos errôneos mais comuns que têm
feito as empresas se tornarem vítimas quando se tratam de práticas
ágeis”.
A reportagem traz uma listagem realizada por especialista sobre falhas
que estão sendo cometidas quando utiliza métodos ágeis. Falhas como

confusão na estimativa de orçamento, rapidez na hora de escolher os
membros da equipe de trabalho, não ter resistência na estrutura orga-
nizacional, entender que os princípios são diretos e fáceis de assimilar,
mas difíceis de integrar, acreditar que o método ágil acabou devido a
outros que surgiram, pois, ainda é muito utilizado e adotado nas empre-
sas. Os demais pontos listados você poderá ver na reportagem.
Fonte: Portal cio
Data:20/10/2019
Leia a notícia na íntegra: <https://cio.com.br/5-erros-que-podem-ser-
-fatais-na-implementacao-de-metodologias-ageis/> Disponível dia 11
de Abril 2020
NA PRÁTICA
O uso de recursos lúdicos para o ensino de processos em Engenharia

de Software
Docentes e alunos têm enfrentado grande dificuldade no que se refere à
abordagem de ensino-aprendizagem do uso de processos na disciplina
de Engenharia de Software, pois, a maioria das metodologias adota-
das atualmente se baseiam em aulas expositivas com pouca eficiên-
cia. Neste artigo é apresentada uma abordagem diferente, que utiliza
51
recursos lúdicos para o auxílio ao ensino de processos, com o objetivo
de melhorar a absorção de conhecimento pelos alunos e, consequen-
temente, trazer para a prática conhecimentos somente vistos na teoria.
Fonte:<https://sol.sbc.org.br/index.php/wei/article/view/9670>
PARA SABER MAIS
Filmes sobre o assunto: A Rede Social

Ano: 2010
Acesse os links:<https://www.youtube.com/watch?v=h4LRRVXqhpI&-
feature=youtu.be>
INDICAÇÕES BIBLIOGRÁFICAS
Leia mais em:
<http://www.scielo.br/scielo.php?script=sci_arttext&pid=S1415-655520
18000300443>, que diz respeito a Concursos Públicos Docentes em
uma Universidade Federal: Proposta de Melhorias em Software.
52
REQUISITOS DE

ENGENHARIA DE SOFTWARE
O presente capítulo, em sua primeira parte, versará sobre a

contextualização dos requisitos de software já tão falados ao longo dos
capítulos anteriores.
Dessa forma, agora vamos buscar entender o conceito e as
técnicas para poder encontrá-los. Já podemos perceber que os requi-
sitos estão relacionados diretamente com cliente e que bons requisitos
contribuem para entrega de um produto de software satisfatório.
Com isto, iremos abordar ainda neste capítulo, as técnicas
para realizar o levantamento de requisitos, como também entender a
diferença entre os requisitos de sistema e requisitos de software. Será
demonstrado como elaborar um documento de requisito e como eles
são formados.
Ainda serão abordados o processo de teste e a revisão de
software e como estes são importantes para implantar o software com
qualidade. Também será dado um enfoque à manutenção do software.
53
REQUISITO DE ENGENHARIA DE SOFTWARE: CONCEITUAÇÃO
Conforme Thayer e Dorfmann (2000) determinam que requisito

é uma propriedade do software precisa para que o cliente possa desco-
brir a solução de um problema de modo a alcançar um objetivo.
Compreende que os requisitos são definições de serviços for-
necidas pelo sistema, ainda que os requisitos descrevem as necessi-
dades dos clientes de um software, contribuindo para solucionar algum
problema, como por exemplo, buscar uma informação, cadastrar um
produto. Outros autores definem que os requisitos são como uma des-
crição completa de que o software proporciona fazer sem expor o como
fazê-lo (LOPES apud SIDDIQI, 1996).
Após entendermos as definições dos requisitos podemos ob-
servar que estes são de suma importância na produção do software,
por serem as características necessárias que o compõem, por meio dos
requisitos são atendidas as solicitações dos clientes.
Outra importância dos requisitos de software bem definidos
acaba por determinar as necessidades dos clientes e do fornecedor so-
bre qual objetivo do software, possibilita serem uma referência para a
validação do produto final, ainda contribui também para redução de cus-
to de desenvolvimento, pois, requisito mau definido gera desperdício de

tempo para refazer. Em contra partida o levantamento inadequado dos
requisitos pode gerar uma série de problemas como:
• O sistema ser construído e finalizado resolvendo outro proble-
ma diferente do requisitado pelo cliente.
• O sistema não ter as funcionalidades como o esperado, ge-
rando a insatisfação do cliente.
• O sistema apresenta dificuldade para usuário compreender e
utilizá-lo.
• Alto custo de tempo e dinheiro
Ter atenção na hora de definir os requisitos de software está

diretamente relacionado com sucesso do software. Por isso é muito im-
portante realizar esta atividade com cuidado e atenção à real necessi-
dade do cliente. Pois, uma vez definidos os requisitos, será construindo
o software e só depois quando for validada a funcionalidade, durante o
processo, poderá ser vista ou não a falha no requisito, com isso, gerará
um custo de tempo para refazer a funcionalidade.
54
Requisitos de sistema e requisitos de software
No processo de obtenção de requisitos por parte dos enge-
nheiros de requisitos e projetistas, ocorre muitas vezes uma dificuldade:
a falta de esclarecimento na descrição dos diferentes níveis de especifi-
cação de requisitos entre os envolvidos do processo de desenvolvimen-
to do software (Sommerville, 2007).
Os requisitos são divididos entre dois tipos diferentes: requi-
sitos de sistema e requisitos de usuário. Os requisitos de sistema cor-
respondem as funcionalidades, os serviços e as exceções operacionais
do sistema são abstratos de alto nível. E geralmente são classificados
como funcionais e não funcionais.
Assim, é necessário um documento de requisitos do sistema,
que traz uma descrição detalhada do que será implementado no siste-
ma. Estes ainda são classificados como requisitos funcionais, não fun-
cionais ou de domínio, conforme Sommerville (2007).
• Requisitos funcionais: refere-se às tarefas que o sistema ofe-
rece, detalhando e verificando como o sistema se comporta com deter-
minadas ações, após uma determinada entrada. As vezes descreve o
que sistema não pode fazer.
- Exemplo: um sistema de venda teria como requisito funcional

cadastrar um cliente, efetuar uma compra, buscar um produto.
• Requisitos não funcionais: não corresponde às funcionalida-

des diretamente, podem corresponder a restrições que o sistema possui
e propriedades, como por exemplo: tempo de resposta, confiabilidade,
qualidades do software, custo, manutenção, usabilidade, desempenho,
portabilidade, entre outras. Estes podem ser mais problemáticos que
requisitos funcionais, pois, havendo uma falha em corresponder um re-
quisito não funcional do sistema pode inutilizá-lo.
- Exemplo: capacidade dos dispositivos de entrada e saída,
representações de dados.
O software deve garantir que o tempo de resposta às consultas
não sejam maiores do que sete segundos.
• Requisitos de domínio tem sua origem no domínio da aplica-

ção do sistema e correspondem às características desse domínio, po-
dendo ser requisitos funcionais ou não funcionais. Estes podem corres-
ponder a novos requisitos funcionais, como pode determinar restrições
para os requisitos funcionais existentes, ou estabelecer como efetuar
cálculos específicos.
- Exemplo: Em um sistema acadêmico o cálculo da média final
55
de um aluno é dado pela fórmula: (Nota1 + Nota2 +Nota 3)/3;
Um aluno só pode obter um livro na biblioteca após ser veri-
ficado se ele não tem nenhuma inadimplência com a biblioteca, esta
verificação é um pré-requisito para realizar o empréstimo.
• Os requisitos de usuário correspondem a descrever, em uma

linguagem natural com diagramas, os requisitos funcionais e não funcio-
nais e as restrições que eles devem realizar de uma forma compreensí-
vel pelos usuários que não têm conhecimento técnico detalhado. Este
serve para expressar somente o comportamento externo do sistema,
devendo evitar uso de linguagens técnicas de projeto nos requisitos de
usuário.
- Exemplo: Utilizar de diagramas simples e práticos como for-
mulários.
Alguns problemas encontrados com uso de língua natural:

• Carência de clareza: ambiguidade e falta de concisão, origi-
nando um documento que apresenta uma difícil compreensão.
• Confusão: os requisitos funcionais e não funcionais, podendo
estar descritos de modo confuso com as informações sobre o projeto
não estarem bem definidas.
• Fusão de requisitos: diversos requisitos distintos podem ser

explanados juntos, como se fosse um único requisito.
Requisitos não funcionais são referentes ao sistema como um

todo. Alguns podem oferecer restrição ao processo que é usado para
desenvolver o sistema, como definir uma linguagem de programação ou
processo de desenvolvimento.
Técnicas de levantamento de requisitos

Após entendermos sobre os requisitos do software e os seus
tipos, é importante conhecer as técnicas de levantamento de requisitos.
Existem diversas técnicas que são usadas para facilitar o processo de
adquirir requisitos. Estas contribuem para comunicar-se entre os clien-
tes e projetistas do sistema, oferecendo meios apropriados para adquirir
requisitos distintos e solucionar problemas.
56
Assim, existem várias técnicas de levantamento de requisitos
e a escolha se dá de acordo com o contexto do problema. Algumas téc-
nicas serão citadas abaixo.
Entrevistas
A entrevista é uma das técnicas de levantamento de requisitos
mais adotada. Esta pode ser percebida quando o membro da equipe do
projeto de software tem a responsabilidade de discutir com os usuários
e/ou clientes com objetivo de fazer o levantamento dos requisitos, por
meio da discussão de ideais sobre o sistema a ser desenvolvido. Para
obter os requisitos, utilizam de elaboração de questões, para serem
abordadas com cliente, a fim de que, depois possa ser feito um filtro, do
que se tornará possíveis requisitos do sistema.
Sommerville (2007) afirma que existe, de modo básico, dois
tipos de entrevistas: as entrevistas estruturadas, perguntas são criadas
antecipadamente e o stakeholder (pessoas interessadas no projeto) irá
respondê-la do modo como foram idealizadas; já as entrevistas aber-
tas não correspondem a nenhum itinerário predefinido de questões, a
pessoa delegada explana vários temas, de acordo com a finalidade de
encontrar um maior entendimento sobre operações do stakeholder.

As vantagens desta técnica são a flexibilidade de obter as in-
formações e a aproximação do cliente com a pessoa delegada a buscar
os requisitos. Os engenheiros de requisitos geralmente ficam a cargo
desta responsabilidade. Permitindo assim, nessa aproximação, que o
usuário se sinta mais atuante no processo do software.
Algumas desvantagens das entrevistas são: a dificuldade de
analisar o volume de dados obtidos, avaliar a qualidade dos dados que
foram coletados e a habilidade de lidar com as entrevistas.
Questionário
Outra técnica bastante comum para o levantamento de requisi-
tos é questionário, que pode ser aplicado em grande escala por meio de
sua estrutura. A utilização deste além de colaborar com grande número
de pessoas também é pertinente utilizá-lo quando não é possível en-
contro físico, ou até mesmo quando é necessária uma amostra estática
da quantidade de pessoas que usaram o software, por exemplo.
Uma das contribuições dos questionários é pode adquirir um
retorno de muitas pessoas sobre o sistema requisitado, porém, existem
algumas desvantagens nesta técnica, que justamente sua elaboração
que não é nada fácil, por necessitar ser elaborado por perguntas obje-
57
tivas, claras e sem ambiguidades sobre o sistema. É necessário adotar
uma metodologia para a elaboração das questões, personalizada con-
forme o perfil dos usuários, evitando o uso de termos técnicos.
Análise de observação
A técnica da análise de observação é bem interessante, pois,
permite que a inclusão do desenvolvedor do projeto na atmosfera de
trabalho em que o usuário ou grupo de usuários estão inseridos, na
qual este desenvolvedor observará as atividades cumpridas pelo usuá-
rio, sem intervir no ambiente de trabalho.
O objetivo é poder encontrar os requisitos por meio desta ob-
servação e análise das atividades realizadas pelo usuário. Até mesmo
é uma boa técnica para poder obter, de modo eficaz, o levantamento de
informações que, caracteristicamente, poderiam passar despercebidas
se fossem utilizadas outras técnicas.
Interessante é que uma das técnicas de observação adotada

para o levantamento de requisitos, muito usada no campo das ciências

sociais, é a etnografia, que nada mais é do que realizar a observação
do cotidiano do usuário, com o objetivo de registrar todas as atividades
reais realizadas pelos usuários envolvidos.
Join application development - JAD

Joint Application Development (JAD) é uma técnica que foi
idealizada pela IBM, que trata de buscar realizar o levantamento de
requisitos, com o intuito de primar pela criação de sessões de tarefas
estruturadas, por meio de uma dinâmica de grupo e de auxílios visuais,
em que os stakeholders envolvidos trabalham no intuito de buscar os
requisitos básicos até como layout de telas e relatórios do sistema a ser
desenvolvido (CARVALHO, 2003).
Algumas características desta técnica são: uns processos or-
ganizados e estruturados, cada sessão JAD suscita um documento que
seja simplificado e de fácil compreensão, e este criado em concordância
com todos os participantes, o encontro destas sessões acontecem entre
3-5 dias.
Outro ponto importante é que esta técnica trabalha com a dinâ-
58
mica de grupo, em que tem um facilitador, com o objetivo de mediar e
interagir com os participantes nas reuniões, buscando os requisitos do
sistema.
Como também a metodologia adotada por esta técnica contém
duas grandes fases: planejamento, na qual tem o fim de levantar e es-
pecificar requisitos; e o projeto do software (CARVALHO, 2003).
Prototipação
A utilização desta técnica é apresentar ao usuário uma amostra
de uma versão do software, para que ele possa utilizar fazendo uma
experiência e uma avaliação para analisar o que está faltando. Esta
técnica é interessante porque possibilita que usuário possa ter uma vi-
são mais ampla do sistema, antes mesmo deste estar pronto, podendo
assim avaliar o que necessita, o que tem e o que precisa ser feito.
Alguns benefícios desta técnica é poder validar os requisitos
encontrados com os usuários e também contribuir na idealização do
projeto de interface, pois, os usuários podem validar o que foi apresen-
tado e dar sugestões de melhorias.
Um ponto crítico de utilizar este processo para o levantamento
de requisitos é usar essa estrutura para a primeira versão do software,

após o cliente saber que precisa ser refeito para poder obter um nível
de garantir qualidade.
A prototipagem foi o modelo de processo que estudamos no

capítulo 2, porém, nesta sessão estamos vendo que ele também serve
para captar requisitos para o sistema. Perceba como este modelo pode
ter duas funções muito importantes.
Casos de uso
Outra técnica muito utilizada para o levantamento de requisito
é o modelo de caso de uso. Esta modelagem se baseia em uma nota-
ção gráfica objetiva e uma representação em linguagem natural, o que
permite uma facilidade de comunicação para o usuário, fornecendo uma
modelagem simplificada para encontrar os requisitos.
Com isto, temos que o conjunto de casos de uso representa,
de modo visual, todas as possibilidades de interação que serão defini-
59
das nos requisitos de sistema. O modelo de caso de uso é formado por
atores, que representam pessoas ou outros sistemas, são ilustrados
como figuras “de bonecos em formato de palito”. Em que cada classe
de interação é ilustrada por uma elipse. As linhas conectam os atores e
a interação. Como opção, pontas de flechas podem ser acrescentadas
às linhas para demonstrar como a interação se inicia (SOMMERVILLE,
2011). Abaixo temos a figura 8 que ilustra um modelo de caso, conforme
descrevemos aqui.
Figura 8- Modelo de Caso de Uso

FONTE: a autora, 2020.
Observamos na figura 8, que é um exemplo de como é repre-

sentando um modelo de caso de uso, que cada ator ilustrado, como
boneco, representa um papel de um usuário, a conexão é realizada por
meio das linhas e dentro da figura, com formato elíptico, está um requi-
sito do sistema. Para modelar um caso de uso é só escolher dentre as
diversas ferramentas que existem, por exemplo: a ferramenta ASTHA.
No caso de uso, pode ter o ator principal e/ou secundário, a
diferença é a interação onde no principal ocorre de modo direto com
o sistema, e já com secundário a interação ocorre com outros atores.
Exemplo: no sistema de biblioteca quem cadastra o livro é o bibliote-
cário, então seria o ator principal, já o aluno solicita ao bibliotecário o
empréstimo.
Vale salientar que os modelos de caso de uso incorporaram a
60
Linguagem de Modelagem Unificada (UML), que é estrutura por diagra-
ma de casos de uso. (BEZERRA, 2006).
Um ponto importante a ressaltar é que o modelo de caso de

uso, além de poder servir como técnica de levantamento de requisitos
pode ser utilizado, para outro fim, como ser base para o documento de
requisito.
DOCUMENTO DE REQUISITOS
A norma IEEE - Institute of Electrical and Electronic Engineers

(1996) relata que o documento de requisitos, tem como objetivo des-
crever de modo claro seus requisitos. Outros atributos essenciais no
documento são a necessidade de que ele possibilite a verificação, con-
sistência, modificação, rastreabilidade e usabilidade durante todas as
fases do ciclo de vida do requisito. Em suma, o documento de requisitos

de software é a declaração que estabelece os requisitos do sistema.
Outra definição dada por Coelho (2009), p. 34, sobre documentos dos
requisitos é:
“Documentação descreve cada parte do código fonte, uma função, uma clas-
se, um trecho ou módulo. Podemos dizer que a documentação consiste em
um conjunto de manuais gerais e técnicos, podendo ser organizado em for-
ma de textos e comentários, utilizando ferramentas do tipo dicionários, dia-
gramas e fluxogramas, gráficos, desenhos, dentre outros.”
Existem objetivos importantes que formam o documento de re-

quisito, como ser um elemento de apoio entre o cliente e a equipe de
desenvolvimento, serve como base para produzir o software, pois, nele
estão detalhadas as especificações e as restrições que o sistema deve
ter. O documento ainda contribui nos processos de verificação e valida-
ção, bem como proporciona o rastreamento dos requisitos e as fases de
manutenção e evolução do software.
Alguns papéis dos membros da equipe de desenvolvimento de
software relacionando com documento de requisito:
• Clientes do sistema: solicitam e verificam se os requisitos
atendem as suas necessidades; também especificam a necessidade de
alguma alteração;
61
• Gerentes: utilizam o documento para traçar o planejamento
do processo de software;
• Engenheiros de software: têm a responsabilidade de enten-
der que sistema deverá ser desenvolvido;
• Engenheiros de teste: têm a responsabilidade de criar testes
de validação do sistema;
• Engenheiros de manutenção: têm a responsabilidade de en-
tender o sistema e as relações entre suas partes.
Vale destacar que a documento de requisito é elaborado no
decorrer do desenvolvimento do software, e que ele é de suma impor-
tância neste processo. Pois, permite ao cliente e à equipe de desenvol-
vedores terem uma visão do todo software, podendo reavaliar alguma
funcionalidade ou fazer melhoria futura, de modo mais eficiente, por
terem os requisitos todos descritos.
Por outro lado, problemas de compreensão, confusão de fun-
cionalidades, dificuldade de realizar a manutenção do sistema podem
ser ocasionados devido à falta de documentação.
O Padrão IEEE/ANSI 830 (1993) determina de modo geral, ele-
mentos que formam um documento de requisitos: introdução, descrição
geral, requisitos funcionais e não funcionais, apêndices e sumário. Con-
tudo, ainda podem ter outros elementos no documento, como definição
de arquitetura de sistemas, processo de software e melhoria do sistema.
Rastreabilidade de requisitos
A rastreabilidade é a característica de especificar requisitos
que demonstra a facilidade de descobrir os requisitos relacionados
(SOMMERVILLE, 2007). Nisto compreende que essa técnica funciona
como um procedimento de detectar e registrar o elo que circunda um
determinado requisito, para que possa rastrear de onde é originado,
como os componentes ligados ao mesmo e aos outros requisitos pro-
priamente dito.
Porém, para um requisito ser considerado rastreável, ele ca-
rece de algumas condições, como ter um identificador. Assim que con-
seguimos identificar os requisitos, tabelas de rastreamento são elabo-
radas.
Nisto essas tabelas catalogam os requisitos identificados a um
ou mais elementos de sistema ou de sua atmosfera. No meio das várias
tabelas de rastreamento admissíveis podemos ter os seguintes exem-
plos:
• Características: referindo-se à evidência como os requisitos
pode se comporta no sistema na visão do cliente;
62
• Fonte: referindo-se a detectar a origem de cada requisito;
• Dependência: demonstra como os requisitos estão se com-
portando, ou seja, se relacionam;
• Subsistemas: refere-se aos requisitos determinados pelos
subsistemas que eles geram;
• Interface: trata da relação dos requisitos entre as interfaces,
sejam internas e/ou externas do sistema (PRESSMAN, 2006).
Algumas contribuições geradas por essa técnica são: ter uma
avaliação de impacto, de modo acelerado e simplificado, o que possi-
bilita poder realizar a estimativa de alterações em cronogramas e em
despesas com o projeto.
Possibilita ainda encontrar lacunas e falta de consistência nos
requisitos, como também validar se a resolução de uma função está
coerente com que foi proposto, tem uma grande importância ainda na
gestão de riscos, pois, requisitos que tenham muita dependência ofere-
cem um risco maior.
Outras características dessa técnica são os tipos relacionados
com a capacidade de rastrear, em que temos o tipo de rastrear para
frente, que corresponde à aptidão de rastrear um requisito até seus apri-
moramentos, e outro tipo de rastrear para trás, que corresponde a ras-
trear até sua origem. Esses dois tipos precisam ser atuantes em todos

os tipos de rastreabilidade, se não houver, acaba gerando um processo
errôneo.
Ainda podemos destacar outros tipos de rastreabilidade que
são:
• Rastreabilidade horizontal: Aborda as várias versões de re-
quisitos ou artefatos em uma fase do ciclo de vida. E também está rela-
cionado com rastrear a dependência entre os diversos requisitos, per-
mitindo uma visão maior sobre os impactos.
• Rastreabilidade vertical: aborda os requisitos ou artefatos ela-
borados ao decorrer do ciclo de vida do projeto.
• Pré-rastreabilidade: está compreendida na identificação da
origem dos requisitos.
• Pós-rastreabilidade: detecta quais componentes implemen-
tam um determinado requisito.
Outro elemento que contribui no processo de rastrear requisi-
tos é a matriz de rastreabilidade, que é um instrumento que disponibiliza
a visualização das iterações entre os requisitos e outros artefatos ou
objetos.
Exemplificando: aloca os objetos, sendo rastreados nas linhas
de uma tabela e demarca os pontos de intersecção. Assim, a matriz
contribui para analisar o relacionamento dos requisitos aos membros
63
envolvidos no projeto, aos outros requisitos ou aos módulos de projeto.
Podemos extrair importantes informações de rastreabilidade
como:
• Informações de rastreabilidade de origem: designam requi-
sitos aos stakeholders que sugeriram esses requisitos, assim, quando
uma alteração é solicitada, pode ser mais simples encontrar os stakehol-
ders e buscá-los.
• Informações de rastreabilidade de requisitos: conectam requi-
sitos que têm alguma dependência dentro do documento de requisitos,
assim, quando for necessário efetuar alguma modificação será facilita-
da por esta informação, de já saber quantos requisitos serão afetados
pela alteração proposta.
• Informações de rastreabilidade de projeto: conectam os requi-
sitos aos módulos de projeto em que esses requisitos são implementa-
dos, proporcionado avaliar o impacto das modificações no projeto e na
implementação.
Estudo de viabilidades técnica e econômica

Compreende o estudo de viabilidades técnica e econômica
como aquele que possibilita decidir a viabilidade de desenvolver ou não
um determinado sistema. Algumas perguntas são importantes e preci-

sam ser levantadas para avaliar se vale a pena desenvolver. Perguntas
como:
• O sistema fornece os objetivos da organização?
• Há possibilidade de ser implementado com a tecnologia atual
e dentro do orçamento proposto?
• Há possibilidade de ser integrado a outros sistemas em ope-
ração?
• O que acarretaria se o sistema não fosse implementado?
• Quais os problemas com os processos atuais?
• Como o sistema idealizado poderá ajudar?
• Pode existir troca de informações entre outros sistemas e o
sistema idealizado?
Vale ressaltar que existem alguns outros tipos de viabilidades
a serem consideradas e avaliadas no desenvolvimento do software: a
viabilidade organizacional, a operacional, a técnica, a de cronograma, e
a econômica, que é uma das mais críticas e entre outras.Veja abaixo a
descrição destas:
• Viabilidade organizacional: está direcionada a quanto a reso-
lução contribui para a organização. Avalia se o usuário aceitará a solu-
ção proposta, tendo em vista a cultura do ambiente organizacional e a
64
adesão dos envolvidos no projeto. Então são verificados se o planeja-
mento e os objetivos da organização foram atendidos.
• Viabilidade operacional: está direcionada à adequação da re-
solução na organização; a definição dos requisitos da resolução e a
expectativa do cliente quanto ao que espera do sistema;
• Viabilidade técnica: está relacionada ao suporte e à manuten-
ção técnica que a organização disponibilizará para o desenvolvimento
do projeto; como limitações dos envolvidos ou de recursos tecnológicos.
• Viabilidade de cronograma: está direcionada à relação entre
as tarefas levantadas e o tempo considerado para concluir cada uma;
definição de limites do projeto; os conflitos de atrasos.
• Viabilidade econômica: examina e avalia a relação do custo
de desenvolvimento e as contribuições deste depois da implementação
do projeto.
• Esta é uma das mais críticas, em que os envolvidos no projeto
devem levar em consideração também a relação de custo e beneficio.
Alguns tipos de custos que são importantes avaliar, por exemplo: custos
de desenvolvimento de sistemas, de equipe, custo com hardware, com
treinamento, com recursos tecnológicos, com licenças de softwares.
Assim, estes custos necessitam ser avaliados e comparados com os
benefícios que o sistema pode gerar.

E após analisar as informações, que ajudam a determinar a
viabilidade do projeto de software, é tomada a decisão, para saber se o
software será desenvolvido. Em caso afirmativo é assinado um termo,
que é um documento que permite formalizar a aprovação do projeto e
autorizar o início das tarefas de desenvolvimento do projeto.
TESTES E REVISÃO DE SOFTWARE
O teste de software é uma importante etapa no processo de

desenvolvimento, pois, por meio dele é possível identificar e resolver
problemas no software. No decorrer de todo o desenvolvimento, tarefas
são executadas para garantir a qualidade do sistema, porém, a possi-
bilidade de prosseguir descobrindo erros é comum, mesmo depois da
finalização do desenvolvimento do software.
Pressman (1995) afirma que na fase de testes, os engenheiros
executam uma série de tarefas que versam em fazer uma varredura no
software, buscando algum tipo de erro ou deficiência na codificação,
que possam vir a interferir no funcionamento correto do sistema. O teste
tem responsabilidade de identificar o maior número possível de erros,
porque descobrir todos é extremamente impossível.
65
Vale ressaltar que o principal objetivo do teste é avaliar o siste-
ma, verificando se existem problemas e falhas, sendo assim, uma tarefa
investigativa que ocorre durante todo o processo de desenvolvimento
do software, com intuito de encontrar problemas.
Porém, é importante entender que testar, em sua definição bá-
sica, não implica em apenas demonstrar que o software funciona corre-
tamente, mas sim que as técnicas são adotadas para abordar todas as
possíveis causas de um mau funcionamento e que os testes necessitam
ser adequados, e encontrar o máximo possível de falhas e erros ( BAS-
TOS et al. 2007).
Ainda podemos destacar que os objetivos dos testes podem
ser relacionados a fazer a varredura no sistema em busca de erros, ou
por meio da especificação no projeto de teste, sendo criados testes para
os requisitos funcionais, como também verificando o desempenho de
algum requisito não funcional.
Sendo assim, temos algumas fases de teste que apresentadas
abaixo:
• Teste de Unidade: referente a detectar os erros de lógica e de
codificação em cada módulo do software, separadamente.
• Teste de Integração: referente identificar erros relacionados
às interfaces entre os módulos do software.
• Teste de Sistema: referente a verificar se as funções estão

conforme o que foi especificado e se todos os elementos do sistema
estão adequadamente.
As etapas que compõem o teste são o planejamento, o projeto
de casos de teste e a execução do programa, com os casos de teste,
finalizando com análise de resultados.
Implantação de software
Esta fase de implantação de software tem a responsabilidade
de possibilitar a instalação do software ao ambiente requisitado de pro-
dução. Assim, temos que nesta etapa o projeto é apresentado para os
envolvidos no projeto e aos clientes, e é avaliado se necessita de algu-
ma observação, de modificações ou refinamento do produto, caso haja
será retornando após o ajuste, depois de ser aprovado.
Porém, após à aprovação do cliente e da equipe de desenvol-
vimento, começa a preparação de manuais e são planejados os treina-
mentos.
Assim, temos as seguintes tarefas realizadas nesta fase de im-
plantação:
• O treino dos usuários;
66
• A configuração do ambiente de produção;
• E a realização, se preciso, da conversão da base de dado;
Manutenção do software
Após o sistema ser entregue ao cliente e colocado em execu-
ção, começa a fase de manutenção ou também chamada de evolução
do software. Levando em consideração os altos custos envolvidos no
processo de adquirir o produto de software, esta fase de manutenção
é um investimento para a empresa, pois, pode ser adotada apenas por
um determinado período de tempo, que for necessária ser realizada.
A necessidade de manutenção pode ser solicitada caso haja
uma mudança de ambiente de software, sendo necessário fazer mo-
dificações para outro ambiente requisitado, isto ocorre por conta dos
sistemas de software terem um acoplamento forte com ambiente.
Outra perspectiva para realizar manutenção é a alteração de
algum componente do sistema, como também adição de algum atributo
às funções já criadas, ou adição de novas funções. Temos as seguintes
fases de manutenção, os passos das fases de definição e o desenvol-
vimento são reaplicados, mas agora no contexto de um software exis-
tente.

Em suma, a fase de manutenção tem grande importância, pois,
é responsável por manter e dar suporte ao sistema em funcionamento,
bem como é responsável por atualizar os elementos. Assim, esta fase
possibilita a melhoria do sistema para suprir a novas demandas das or-
ganizações, como também a correção de possíveis erros ou falhas que
ocorram no sistema.
Podemos citar algumas tarefas de manutenção classificadas
em:
• Manutenção corretiva: referente à correção de alguns defei-
tos apresentados no software, tendo como atividade a alteração da fun-
cionalidade para poder corrigir.
• Manutenção adaptativa: referente a realizar alteração no sis-
tema com funcionalidade de ser executado em outro ambiente diferente
do originado.
• Manutenção evolutiva: referente a acrescentar ou mudar al-
guma funcionalidade do sistema.
67
QUESTÃO 1
Uma das técnicas mais comuns utilizadas para o desenvolvimento/
execução de testes de software é chamada de Caixa-Preta. Selecio-
ne os tipos de teste que são aplicáveis essa técnica:
A - unitário.
B - integração.
C - sistema/funcional.
D - aceitação.
Assinale a alternativa correta.
a) da relação apresentada somente o A, B e C
b) da relação apresentada somente o A, C e D
c) da relação apresentada somente o B, C e D
d) da relação apresentada todos são aplicáveis essa técnica
QUESTÃO 2
No TDD (Test Driven Development) o desenvolvimento deve ser
guiado a testes, onde um teste unitário deve ser escrito antes que
uma funcionalidade do sistema o seja. Assinale a alternativa que
apresenta a que ciclo de vida o processo interativo do TDD deu
origem.
a) green-yellow-refactor
b) red-green-refactor
c) black-white-refactor
d) green-yellow-red-refactor
QUESTÃO 3
ciário - Analista de Informática - Analista de Sistemas e Programação
No âmbito dos testes de integração, a atividade de reexecução de
um mesmo subconjunto dos que já foram executados para asse-
gurar que alterações não tenham propagado efeitos colaterais in-
desejados é conhecida como teste de:
a) unidade.
b) regressão.
c) validação.
68
d) verificação.
e) classe.
QUESTÃO 4
ciário - Analista de Informática - Analista de Sistemas e Programação
Uma estratégia de teste de software pode englobar diferentes tipos
de testes para assegurar a qualidade do software. Os que propor-
cionam a garantia final de que o software satisfaz todos os requi-
sitos informativos, funcionais, comportamentais são conhecidos
como testes:
a) de validação.
b) de unidade.
c) de integração.
d) totais.
e) globais.
QUESTÃO 5
Ano: 2020 Banca: CESPE Órgão: TJ-PA Prova: Analista Judiciário
- Programador
No teste de software orientado a objetos, como a condição de um

objeto é parte implícita da entrada e saída dos métodos, necessi-
ta-se de uma maneira para explorar sistematicamente as situações
e transições do objeto. O modelo de teste adequado para executar
essas operações é o teste
a) interclasse.
b) intraclasse.
c) estrutural.
d) de comando e decisão.
e) com máquina de estado
Após os temas explanados neste capítulo, disserte sobre a importância

do documento de requisitos.
TREINO INÉDITO
Imagine que foi delegado a você realizar o levantamento de requisitos

de um sistema, em que o cliente relata que sua maior necessidade é
uma interface intuitiva e simples, por tratar-se de um sistema direciona-
do à venda de produtos online. A partir dos conceitos estudados, assi-
69
nale a técnica de levantamento de requisito que seja mais adequada a
esta necessidade do cliente:
a) Entrevista
b) Questionário
c) Prototipação
d) Modelo de caso de uso
e) Análise da observação
NA MÍDIA
“BI: O que é importante e na fase de levantamento de requisitos? “
A reportagem parte da afirmativa que “Um bom levantamento de requisi-

tos permite que todo o projeto caminhe de maneira mais fluida e rápida”,
relatando a importância da fase de levantamento de requisito, tendo em
vista que esta compreende traduzir o que o cliente deseja como solução
final. Assim, para que se tenha esse objetivo, é necessário que haja um
bom planejamento de todas as fases do projeto, incluindo a parte de
levantamento de requisitos.
Nisto é frisado quando não há a devida atenção nessa etapa do projeto,
geram problemas, como solução final insatisfatória ou erros na valida-

ção dos dados podem ocorrer, gerando insatisfação do cliente e neces-
sário refazer o trabalho à consultoria. Deste modo, este ponto é muito
crítico, pois, esta etapa exige maior atenção no início, sendo crucial
para acarretar o sucesso do software e a satisfação do cliente.
Fonte: (Portal cio)

Data: 26/09/2018
Leia a notícia na íntegra:<https://cio.com.br/bi-o-que-e-importante-na-
-fase-de-levantamento-de-requisitos/>
NA PRÁTICA
“As 6 etapas fundamentais de um projeto de software”
O texto abordará seis etapas fundamentais para tirar um projeto de sof-

tware do papel, a primeira citada foi conhecer a necessidade do clien-
te por meio de reunião, entendendo as expectativas dele e fazendo a
estimativa do orçamento que deseja para investir no projeto, após a
reunião definir os requisitos, que é o segundo ponto. A listagem
exposta coloca em terceira a avaliação da viabilidade, em que deseja
70
por meio da análise, a criação do projeto de software, para evitar retra-
balho, como assumir responsabilidades que não podem ser cumpridas.
Outro ponto citado como importante é a documentação, em que serão
elaboradas as documentações que registram o que será desenvolvido
e como o processo terá que acontecer. Ainda lista a escolha da meto-
dologia de desenvolvimento, e a realização de testes a serem feitos no
software. Em ênfase é citada é avaliação dos riscos para evitar qualquer
tipo de problema futuro, bem como cita a importância da utilização de
backups e atualização destes, como um recurso para o processo de
software.
FONTE:<https://becode.com.br/etapas-de-um-projeto-de-software/>
Filme sobre o assunto: Apollo 18

Ano: 2011
Disponível em: <https://www.youtube.com/watch?v=7e2c1NZyBcw>
Acesso em: 13 de abr. 2020.
71
Finalizando o presente módulo, espera-se que o aluno tenha
adquirido um conhecimento efetivo na área de Engenharia de Software
e possa ter a capacidade de entender seus princípios e métodos.
Inclusive que os alunos possam sair com a compressão da
grande importância de um bom planejamento de projeto, quando se tra-
balha com processo desenvolvimento de software, levando em conta
a boa comunicação, um bom planejamento e a escolha adequada do
processo de software.
Ainda espera-se que o conteúdo explanado possa levar você
a ser um profissional qualificado e comprometido com a qualidade de
produzir, manter e avaliar bons softwares. Como também deseja trazer
com os temas abordados, que no futuro possa ser um profissional que
tome boas decisões, de acordo com os conhecimentos adquiridos. Po-
demos constatar a importância da Engenharia de Software no mercado
e como é necessária a existência de profissionais qualificados nesta
área.
Em suma, almejamos que todos os temas explanados sejam
de grande valia para o seu crescimento profissional, bem como pessoal,
e que contribua como inspiração para viabilizar a garantia de um bom
desempenho, em uma carreira de sucesso.
72
GABARITOS
CAPÍTULO 01
01 02 03 04 05
Certo B E E C
QUESTÃO DISSERTATIVA – DISSERTANDO A UNIDADE – PADRÃO

DE RESPOSTA
Podemos inferir com a figura 2 do capítulo, que muitos dos problemas

dos projetos podem ser descartados no meio do processo, por levarem
tanto tempo para serem projetados, que acabam se tornando obsoletos.
Muitas vezes isso se deve pela equipe não entender o que realmente foi
solicitado pelo cliente e a solução do software acaba necessitando de
mais tempo de implementação. Em suma, a imagem traz uma grande
mensagem para o processo de desenvolvimento de software, que é de

estabelecer uma boa comunicação entre cliente e a equipe de desen-
volvedores, para assim, estar sempre validando as funcionalidades se
estão de acordo com o solicitado.
TREINO INÉDITO
A resposta correta é a letra A, que traz de modo correto alguns dos

princípios da Engenharia do Software: rigor, abstração e modularidade.
Já as letras B e E estão erradas, por trazer ferramenta que é um termo
que compõe uma das camadas de Engenharia de Software. A letra C
também traz outra camada que compõe a Engenharia de Software, o
método. Por fim, temos a letra D, que é errada também porque traz o
conceito de processo, que é outra camada que compõe a Engenharia
de Software. Pois, temos o seguinte conceito, que a Engenharia de Sof-
tware trabalha com essas camadas, método, processos e ferramentas,
relacionando-as à qualidade e ao aprimoramento dos procedimentos.
73
CAPÍTULO 02
01 02 03 04 05
B E D C B

DE RESPOSTA
Alguns dos valores da metodologia XP são a comunicação, que tem a

ênfase em construir uma compreensão entre os envolvidos do proble-
ma, desejando usar a mínima documentação formal e usar ao máximo
da interação com os envolvidos no projeto, para entender o escopo. Ou-
tro valor que pode ser citado é o de feedback: esse é super importante
porque oferece um retorno para os programadores sobre o projeto, até
mesmo para dar ideia de como criar testes. Para os clientes oferece
retorno dos testes criados e das funcionalidades como todo.
TREINO INÉDITO
Nesta questão, a única assertiva correta é a letra A, pois trata do modelo

espiral e da prototipagem, que correspondem ao modelo evolucionário,
que tem o objetivo de trabalhar com produtos que permitam evoluir ao
longo do tempo. Já as demais letras estão incorretas, pois, trazem ou-
tras combinação referente há modelos de processo de software; a letra
B traz o modelo cascata e V que são modelo sequenciais; a letra C traz
o modelo ágil XP e o modelo sequencial cascata; a letra D traz o mode-
lo sequencial V e o modelo evolucionário espiral ; e a a letra E traz o
modelo ágil XP e o modelo evolucionário de prototipagem.
74
CAPÍTULO 03
01 02 03 04 05
D B B A E

DE RESPOSTA
Vimos neste capítulo que a documentação de requisito é de suma im-

portância no processo de software, porque ela propicia um acompa-
nhamento do que foi feito e o que será feito pelos membros da equipe
no sistema desenvolvido, e possibilita ao cliente também acompanhar
este processo. Outro benefício que é por meio dela, pode ajudar no
processo de manutenção no futuro, pois, observando os registros na
documentação, pode-se consultar um requisito que deseje corrigir e de-
pois modificá-lo, por exemplo. Como também se houver uma adição de
um membro novo na equipe, o impacto não será tão grande, devido ele
poder entender o sistema consultando o documento de requisitos.

TREINO INÉDITO
A reposta correta é letra C, visto que prototipação corresponde à técnica

de levantamento de requisito que mais se adequa à necessidade do
cliente. Assim, esta técnica tem a característica de produzir versões
pequenas do sistema, possibilitando que o cliente possa ver como está
ficando a interface e assim validá-la se está conforme sua necessidade.
Já a letra A traz a entrevista, que não é a mais adequada, pois, apenas
serão abordada perguntas por meio de uma conversa. A letra B traz o
questionário, que não é o mais adequado, pois, trata da formulação de
questões para usuários responderem, serial ideal para um projeto que
tivesse um grande volume de pessoas para ser abordado. E a letra D
traz o modelo de caso de uso, não é o mais adequado, pois, não possi-
bilita ao usuário ver a interface, neste ele pode ver a representação da
ação de uma funcionalidade. Ainda a letra E traz a análise da observa-
ção, que não é mais adequada, pois, trataria de abordar a observação
dos usuários realizando suas atividades.
75
AMBLER,Scott W. Modelagem ágil: práticas eficazes para a progra-
mação extrema e o processo unificado.Trad. Acauan Fernandes.
Porto Alegre Bookman, 2004. 351p.
ACM.The association for Computing Machinery, Inc. and the Institute for
Electrical and Electronics Engineers.1999. Disponível ;http://www.di.ubi.
pt/~sebastiao/Ensino/UBI/2016-2017/API/CodigoEticaACM-IEEE.pdf.
Acesso em: 10 abril 2020.
BASTOS, Aderson; RIOS Emerson; CRISTALLI Ricardo; MOREIRA

Trayahú. Base de conhecimento em teste de Software. São Paulo:
Martins, 2007.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas

com UML. 2. ed.. Rio de Janeiro: Campus, 2006.
COELHO, Hilda Simone. DOCUMENTAÇÃO DE SOFTWARE: UMA

NECESSIDADE 2009.
IEEE, Institute. IEEE Std 830-1998. Recommended Practice for Sof-

tware Requirements Specifications. Institute of Electrical and Eletro-

nic Engineers. Inc. 1998.
FALBO, R. A. Engenharia de Software. Notas de Aula, 2005, disponí-

vel em http://www.inf.ufes.br/~falbo/.
Kendall Scott – O Processo Unificado Explicado, Bookman, 2003
LOPES, Leandro T. Um Modelo de Processo de Engenharia de Re-

quisitos para Ambientes de Desenvolvimento Distribuído de Sof-
tware. Porto Alegre, 2004. 142f.. Dissertação (Mestrado em Ciência da
Computação) – Faculdade de Informática, Pontifícia Universidade Ca-
tólica do Rio Grande do Sul.
MDA explained (The model-driven architecture: practice and prom-

ise). Kleppe, A., Warmer, J. and Bast, W. Object-Technology Series. Ad-
dison-Wesley. 2003.
OLIVEIRA, Fátima B. (Org). Tecnologia da Informação e da Comuni-

cação: articulando processos, métodos e aplicações. Rio de Janei-
ro: E-papers: Fundação Getúlio Vargas, 2009.238p.
76
PRESS. SUH, N. P. (1990). The Principles of Desgin. New York: Ox-
ford University
PRESSMAN, Roger S. Engenharia de Software. 6. Ed.. São Paulo:

McGrawHill, 2006.
PRESSMAN, Roger S. Engenharia de Software. Mc Graw Hill, 6 ed,

Porto Alegre, 2010.
PRESSMAN, Roger, and Bruce Maxim. Engenharia de Software: uma

abordagem profissional-7ª Edição. McGraw Hill Brasil, 2011.
PRESSMAN, Roger, and Bruce Maxim. Engenharia de Software-8ª

Edição. McGraw Hill Brasil, 2016.
SBC.2015. Diretrizes Curriculares de Computação.Disponível em:

https://www.sbc.org.br/documentos-da-sbc.Acesso em: 10 abril 2020
S.L. PFLEEGER, Engenharia de Software: Teoria e Prática, São Pau-

lo: Prentice Hall, 2ª edição, 2004. O Capítulo 2 (Modelagem

SOMMERVILLE, I. Engenharia de Software. 8a Edição. Addison Wes-
ley. 2007.
SOMMERVILLE, Ian. Engenharia de Software.Pearson, 9 ed, São

Paulo,2011.
SUH, N. P. (2001). Axiomatic Design: advances and applications.

New York, EUA: Oxford University
THAYER, Richard; DORFMAN, Merlin. System and Software Requi-

rementsEngineering - Second Edition. Los Alamitos: IEEE Computer
Society Press Tutorial, 2000. 528p
OMG. MDA Guide Version 1.0.1. 2003. Disponível em: <http:// www.
omg.org/docs/omg/03-06-01.pdf>. Acesso em: 10 abril 2020
77
78

Introdução À Engenharia de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Introdução À Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

1

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

PRESIDENTE: Valdir Valério, Diretor Executivo: Dr. Willian Ferreira.

GRUPO PROMINAS DE EDUCAÇÃO

Seja muito bem-vindo(a) ao nosso Grupo Educacional!

Durante o seu curso de graduação você teve a oportunida-

Grupo Prominas - Educação e Tecnologia

É um prazer tê-lo em nossa instituição! Saiba que sua escolha

Estude bastante e um grande abraço!

Professora: Jéssica Laisa Dias da Silva

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

modelos de processo de desenvolvimento, apresentação das técnicas

Engenharia de Software; Processo e desenvolvimento.

Contextualização e Histórico ___________________________________ 13

Problemas Atuais ______________________________________________ 16

Relevância na Área de TI _______________________________________ 19

Processo do Software __________________________________________ 21

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Histórico de Evolução dos Modelos de Processos de Software ___ 32

Processos Ágeis ________________________________________________ 40

Requisito de Engenharia de Software: Conceituação ____________ 54

Documento de Requisitos _____________________________________ 61

Testes e Revisão de Software ___________________________________ 65

Considerações Finais ___________________________________________ 72

Fechando a Unidade ___________________________________________ 73

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Com o passar do tempo, observamos o desenvolvimento dos

O software tem uma grande importância, porque este é res-

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

A evolução do software no decorrer do tempo foi marcada do

cesso sistemático para produção de software, alinhando os conceitos

Figura 1- Camadas da Engenharia de Software

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Temos assim a explicação de cada uma das camadas ilustrada

lação à formalidade é referente a um processo que seja direcionado a

Na seção anterior foi explicado como surgiu a Engenharia do

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Figura 2- Tira do Balanço

FONTE: (FALBO, 2005)

• Mito do Cliente 2: Acreditar que é suficiente realizar apenas

A comunicação contribui para evitar problemas na produção do

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Oliveira (2009) relata que atuar na área da Tecnologia da In-

tências que o engenheiro de software deve atender, sendo algumas de-

“Analisar e selecionar tecnologias adequadas para a construção de software;

Vale ressaltar que existe um Código de ética e práticas profis-

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Na Engenharia de Software, também conhecida como proces-

tarefas como: comunicação, planejamento, modelagem, construção e

Entenda que o processo software não é uma “receita de bolo”

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Conceituação de Software como produto

precisas para que o programa trabalhe de modo correto. Contudo, um

Modelos de ciclo de vida ou modelos de processo

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

cesso é visualizado como um ciclo de vida constituído da especifi-

QUESTÃO DISSERTATIVA – DISSERTANDO A UNIDADE

Disserte sobre a importância da Engenharia do Software no processo

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

PARA SABER MAIS

ENGENHARIA DE SOFTWARE: HISTÓIRIA, CONCEITOS E FUNDAMENTOS - GRUPO PROMINAS

Após entendermos a importância do software e o que conceitua