Apresentação Engenharia de Software I

Prévia do material em texto

Engenharia de Software IEngenharia de Software I
Professor Dr. Gilleanes Thorwald Professor Dr. Gilleanes Thorwald 
Araujo GuedesAraujo Guedes
Engenharia de Software I Engenharia de Software I 
BibliografiaBibliografia
SOMMERVILLE, Ian. Engenharia de Software SOMMERVILLE, Ian. Engenharia de Software –– 66ªª
EdiEdiçção. Addison Wesley. 2003. ão. Addison Wesley. 2003. 
PAULA, Wilson de PPAULA, Wilson de Páádua. Engenharia de Software dua. Engenharia de Software 
–– 22ªª EdiEdiçção. Livros Tão. Livros Téécnicos e Cientcnicos e Cientííficos. 2003.ficos. 2003.
PRESSMAN, Roger. PRESSMAN, Roger. Engenharia de SoftwareEngenharia de Software. . 
Makron Books. 1995.Makron Books. 1995.
GUEDES, Gilleanes. UML 2 GUEDES, Gilleanes. UML 2 –– Uma Abordagem Uma Abordagem 
PrPráática. Novatec, 2009.tica. Novatec, 2009.
GUEDES, Gilleanes. UML 2 GUEDES, Gilleanes. UML 2 –– Guia de Consulta Guia de Consulta 
RRáápida. Novatec, 2005.pida. Novatec, 2005.
Engenharia de Software I Engenharia de Software I 
BibliografiaBibliografia
BOOCH, Grady, RUMBAUGH, James, BOOCH, Grady, RUMBAUGH, James, 
JACOBSON, Ivar. UML Guia do UsuJACOBSON, Ivar. UML Guia do Usuáário rio –– 1010ªª
EdiEdiçção. Campus. 2000.ão. Campus. 2000.
BEZERRA, Eduardo. PrincBEZERRA, Eduardo. Princíípios de Anpios de Anáálise e Projeto lise e Projeto 
de Sistemas com UML. Campus. 2002de Sistemas com UML. Campus. 2002
BENNETT, Simon, SKELTON, John, LUNN, Ken. BENNETT, Simon, SKELTON, John, LUNN, Ken. 
UML. SchaumUML. Schaum’’s Outlines. 2001s Outlines. 2001
MELO, Ana Cristina. Desenvolvendo AplicaMELO, Ana Cristina. Desenvolvendo Aplicaçções ões 
com UML. Brasport. 2002com UML. Brasport. 2002
Engenharia de Software I Engenharia de Software I 
BibliografiaBibliografia
MATOS, A. V. de. Unified Modeling Language MATOS, A. V. de. Unified Modeling Language 
UML PrUML Práático e Descomplicado. tico e Descomplicado. ÉÉrica. 2002.rica. 2002.
FURLAN, J. D. Modelagem de objetos atravFURLAN, J. D. Modelagem de objetos atravéés da s da 
UML. São Paulo: Makron Books, 1998.UML. São Paulo: Makron Books, 1998.
SILVA, D. M. da. UML SILVA, D. M. da. UML –– Guia de Consulta RGuia de Consulta Ráápida. pida. 
NOVATEC. 2001.NOVATEC. 2001.
ALTER, S. Information Systems ALTER, S. Information Systems –– Fourth Edition. Fourth Edition. 
Pearson Education. 2002.Pearson Education. 2002.
Engenharia de Software I Engenharia de Software I --
EmentaEmenta
 PrincPrincíípios da Engenharia de Software. pios da Engenharia de Software. 
Processo de desenvolvimento de software. Processo de desenvolvimento de software. 
Projeto de Software. EspecificaProjeto de Software. Especificaçção de ão de 
requisitos. Trequisitos. Téécnicas de planejamento e cnicas de planejamento e 
gerenciamento de software. Verificagerenciamento de software. Verificaçção, ão, 
teste e validateste e validaçção. Manutenão. Manutençção. Qualidade ão. Qualidade 
de software. Padrões de projeto. de software. Padrões de projeto. Engenharia Engenharia 
reversa. Reengenharia. Engenharia de reversa. Reengenharia. Engenharia de 
Software Apoiada por Computador.Software Apoiada por Computador.
Engenharia de Software I Engenharia de Software I --
ObjetivosObjetivos
 Objetivo Geral:Objetivo Geral:
 Introduzir o aluno nos conceitos da Engenharia de Introduzir o aluno nos conceitos da Engenharia de 
Software, permitindo que este seja capaz de Software, permitindo que este seja capaz de 
elaborar e executar projetos de software, atravelaborar e executar projetos de software, atravéés s 
de tde téécnicas e linguagens de modelagem atuais.cnicas e linguagens de modelagem atuais.
 Objetivos EspecObjetivos Especííficos:ficos:
 Compreender as etapas da Engenharia de Compreender as etapas da Engenharia de 
Software;Software;
 Dominar ferramentas CASE e linguagens de Dominar ferramentas CASE e linguagens de 
modelagem, especificamente UML;modelagem, especificamente UML;
 Elaborar e modelar projetos de software;Elaborar e modelar projetos de software;
Engenharia de Software I Engenharia de Software I 
Procedimentos de AvaliaProcedimentos de Avaliaççãoão
 Provas teProvas teóóricas sobre a matricas sobre a matééria vista (no ria vista (no 
mmíínimo 1, provavelmente 2) com peso 10;nimo 1, provavelmente 2) com peso 10;
 Trabalho PrTrabalho Práático onde um software sertico onde um software seráá
analisado e projetado utilizandoanalisado e projetado utilizando--se uma se uma 
ferramenta CASE e a linguagem de ferramenta CASE e a linguagem de 
modelagem UML, com peso 20.modelagem UML, com peso 20.
 MMéédia composta pela soma das notas e sua dia composta pela soma das notas e sua 
divisão pelo total de avaliadivisão pelo total de avaliaçções ões mais um.mais um.
SoftwareSoftware
 ““Conjunto de instruConjunto de instruçções que quando ões que quando 
executadas produzem a funexecutadas produzem a funçção e o ão e o 
desempenho desejadosdesempenho desejados””;;
Conceitos de Engenharia de Conceitos de Engenharia de 
SoftwareSoftware
““O estabelecimento e uso de sO estabelecimento e uso de sóólidos lidos 
princprincíípios de engenharia para que se possa pios de engenharia para que se possa 
obter economicamente um software que seja obter economicamente um software que seja 
conficonfiáável e que funcione eficientementevel e que funcione eficientemente””
““Estudo ou aplicaEstudo ou aplicaçção de abordagens ão de abordagens 
sistemsistemááticas, econômicas e quantificticas, econômicas e quantificááveis veis 
para o desenvolvimento, operapara o desenvolvimento, operaçção e ão e 
manutenmanutençção de software de qualidadeão de software de qualidade””
Objetivos da Engenharia de Objetivos da Engenharia de 
SoftwareSoftware
 Qualidade de Software;Qualidade de Software;
 DocumentaDocumentaçção de Software;ão de Software;
 Produtividade no desenvolvimento, Produtividade no desenvolvimento, 
operaoperaçção e manutenão e manutençção de software;ão de software;
 Manter o controle de desenvolvimento Manter o controle de desenvolvimento 
dentro de custos, prazos e ndentro de custos, prazos e nííveis de veis de 
qualidade desejados.qualidade desejados.
O Impacto do SoftwareO Impacto do Software
 Atualmente imprescindivel para qualquer Atualmente imprescindivel para qualquer 
pessoa e para a maioria das pessoas, o pessoa e para a maioria das pessoas, o 
software superou hsoftware superou háá muito o hardware em muito o hardware em 
importância;importância;
 Hoje em dia, o software atua em Hoje em dia, o software atua em 
praticamente todas as praticamente todas as ááreas, sendo usado reas, sendo usado 
para auxiliar o ensino, as comunicapara auxiliar o ensino, as comunicaçções, as ões, as 
finanfinançças, enfim, praticamente todas as as, enfim, praticamente todas as ááreas reas 
onde os seres humanos atuam.onde os seres humanos atuam.
O Impacto do SoftwareO Impacto do Software
 O surgimento do software foi um dos O surgimento do software foi um dos 
fatores que possibilitaram o surgimento da fatores que possibilitaram o surgimento da 
era da informaera da informaçção. Nos dias hoje, o ão. Nos dias hoje, o 
software e a forma como ele gere a software e a forma como ele gere a 
informainformaçção ão éé um dos principais fatores que um dos principais fatores que 
determinam o sucesso ou o fracasso de uma determinam o sucesso ou o fracasso de uma 
empresa.empresa.
CaracterCaracteríísticas do Softwaresticas do Software
 O software O software éé projetado por engenharia não projetado por engenharia não 
manufaturado no sentido clmanufaturado no sentido cláássico;ssico;
 O software não se desgasta como o O software não se desgasta como o 
hardware;hardware;
CaracterCaracteríísticas do Softwaresticas do Software
Curva do HardwareCurva do Hardware
CaracterCaracteríísticas do Softwaresticas do Software
Curva Idealizada do SoftwareCurva Idealizada do Software
CaracterCaracteríísticas do Softwaresticas do Software
Curva RealCurva Real
Componentes de SoftwareComponentesde Software
 MMóódulos fonte ou mdulos fonte ou móódulos dulos 
executexecutááveis/interpretados;veis/interpretados;
 Reusabilidade;Reusabilidade;
A Crise do Software A Crise do Software -- ProblemasProblemas
 As estimativas de prazo e de custo As estimativas de prazo e de custo 
freqfreqüüentemente são imprecisas. Sem dados entemente são imprecisas. Sem dados 
histhistóóricos bem documentados não hricos bem documentados não háá como como 
determinar os prazos e os custos com determinar os prazos e os custos com 
precisão.precisão.
 A produtividade das pessoas da A produtividade das pessoas da áárea de rea de 
software não tem acompanhado a demanda software não tem acompanhado a demanda 
por seus servipor seus serviçços;os;
A Crise do Software A Crise do Software -- ProblemasProblemas
 A qualidade de software A qualidade de software ààs vezes s vezes éé menos menos 
que adequada. A insatisfaque adequada. A insatisfaçção do cliente com ão do cliente com 
o sistema o sistema ““concluconcluíídodo”” ocorre com ocorre com 
freqfreqüüência. Os projetos são levados a efeito ência. Os projetos são levados a efeito 
apenas com um vago indapenas com um vago indíício das exigências cio das exigências 
do cliente. A comunicado cliente. A comunicaçção entre o cliente e ão entre o cliente e 
o desenvolvedor normalmente o desenvolvedor normalmente éé fraca.fraca.
A Crise do Software A Crise do Software -- ProblemasProblemas
 A qualidade do software freqA qualidade do software freqüüentemente entemente éé
suspeita. Ssuspeita. Sóó recentemente comerecentemente começçamos a amos a 
entender a importância dos testes de entender a importância dos testes de 
software sistemsoftware sistemááticos e tecnicamente ticos e tecnicamente 
completos.completos.
 O software existente pode ser muito difO software existente pode ser muito difíícil cil 
para manter. A tarefa de manutenpara manter. A tarefa de manutençção de ão de 
software software éé responsresponsáável por 40 a 60% do vel por 40 a 60% do 
custo total do projetocusto total do projeto
Mitos do SoftwareMitos do Software
Mitos AdministrativosMitos Administrativos
 Gerentes sob pressão para manter Gerentes sob pressão para manter 
ororççamentos, prazos e qualidade.amentos, prazos e qualidade.
 Mito: Existência de um manual de padrões e Mito: Existência de um manual de padrões e 
procedimentos.procedimentos.
 Realidade: Ele Realidade: Ele éé usado? Existe usado? Existe 
conhecimento de sua existência? Ele estconhecimento de sua existência? Ele estáá
atualizado? atualizado? ÉÉ completo?completo?
Mitos do SoftwareMitos do Software
Mitos AdministrativosMitos Administrativos
 Mito: Ferramentas de Hardware de Mito: Ferramentas de Hardware de úúltima ltima 
gerageraçção.ão.
 Realidade: Hardware sRealidade: Hardware sóó não adianta, hnão adianta, háá a a 
necessidade de ferramentas de engenharia necessidade de ferramentas de engenharia 
de software auxiliada por computador de software auxiliada por computador 
(CASE (CASE –– ComputerComputer--Aided Software Aided Software 
Engineering).Engineering).
Mitos do SoftwareMitos do Software
Mitos do ClienteMitos do Cliente
 Mito: Em caso de atraso, contratamMito: Em caso de atraso, contratam--se mais se mais 
programadores (horda mongol).programadores (horda mongol).
 Realidade: Acrescentar pessoas a um projeto Realidade: Acrescentar pessoas a um projeto 
atrasado tornaatrasado torna--o mais atrasado ainda.o mais atrasado ainda.
 Mitos do Cliente: Falsas expectativas e Mitos do Cliente: Falsas expectativas e 
insatisfainsatisfaçção.ão.
Mitos do SoftwareMitos do Software
Mitos do ClienteMitos do Cliente
 Mito: Uma declaraMito: Uma declaraçção geral ão geral éé suficiente para suficiente para 
iniciar o desenvolvimento.iniciar o desenvolvimento.
 Realidade: DefiniRealidade: Definiçções errôneas são a principal ões errôneas são a principal 
causa do fracasso. Descricausa do fracasso. Descriçções formais e detalhadas ões formais e detalhadas 
do domdo domíínio da informanio da informaçção, funão, funçção, desempenho, ão, desempenho, 
interfaces, restriinterfaces, restriçções de projeto e critões de projeto e critéérios de rios de 
validavalidaçção são fundamentais. Isto são são fundamentais. Isto sóó pode ser pode ser 
determinado depois de cuidadosa comunicadeterminado depois de cuidadosa comunicaçção.ão.
Mitos do SoftwareMitos do Software
Mitos do ClienteMitos do Cliente
 Mito: O software Mito: O software éé flexflexíível vel ààs mudans mudançças do as do 
projeto.projeto.
 Realidade: O impacto que a mudanRealidade: O impacto que a mudançça a 
causarcausaráá iriráá depender do tempo em que ela depender do tempo em que ela 
ocorrerocorreráá. Se for no in. Se for no iníício, o impacto cio, o impacto éé
relativamente pequeno (5%), caso contrrelativamente pequeno (5%), caso contráário rio 
o aumento do custo o aumento do custo éé muito grande.muito grande.
Mitos do SoftwareMitos do Software
Mitos do ProfissionalMitos do Profissional
 Mitos do profissional:Mitos do profissional:
 Mito: Nosso trabalho acaba ao colocar o Mito: Nosso trabalho acaba ao colocar o 
programa em funcionamento.programa em funcionamento.
 Realidade: 50 a 70% de todo o esforRealidade: 50 a 70% de todo o esforçço sero seráá
dispendido apdispendido apóós a entrega.s a entrega.
 Mito: Não se pode avaliar a qualidade do Mito: Não se pode avaliar a qualidade do 
software enquanto ele não estiver software enquanto ele não estiver 
funcionando.funcionando.
Mitos do SoftwareMitos do Software
Mitos do ProfissionalMitos do Profissional
 Realidade: PodeRealidade: Pode--se garantir a qualidade do se garantir a qualidade do 
software por meio de revisões tsoftware por meio de revisões téécnicas cnicas 
formais.formais.
 Mito: A Mito: A úúnica coisa a ser entregue nica coisa a ser entregue éé o o 
software.software.
 Realidade: A documentaRealidade: A documentaçção garante um ão garante um 
desenvolvimento bem sucedido e fornece desenvolvimento bem sucedido e fornece 
um guia para a manutenum guia para a manutençção.ão.
Ciclo de Vida do SistemaCiclo de Vida do Sistema
Modelo em CascataModelo em Cascata
Modelo em Cascata Modelo em Cascata -- DefeitosDefeitos
 Algumas atividades poderiam ser realizadas Algumas atividades poderiam ser realizadas 
em paralelo;em paralelo;
 Todos os requisitos precisam ser declarados Todos os requisitos precisam ser declarados 
detalhadamente no indetalhadamente no iníício da modelagem, o cio da modelagem, o 
que pode acarretar que um requisito mal que pode acarretar que um requisito mal 
especificado sespecificado sóó seja descoberto quando o seja descoberto quando o 
sistema for implantado;sistema for implantado;
 O sistema sO sistema sóó poderpoderáá ser implantado quando ser implantado quando 
todo o ciclo estiver conclutodo o ciclo estiver concluíído.do.
Abordagem Incremental e Abordagem Incremental e 
IterativaIterativa
Abordagem Incremental e Abordagem Incremental e 
IterativaIterativa
 ÉÉ desenvolvido em vdesenvolvido em váários passos similares rios passos similares 
(iterativo);(iterativo);
 Em cada passo o sistema ganha novas Em cada passo o sistema ganha novas 
funcionalidades (incremental);funcionalidades (incremental);
 Incentiva a participaIncentiva a participaçção do usuão do usuáário, o que rio, o que 
diminui a possibilidade de interpretadiminui a possibilidade de interpretaçções ões 
errôneas.errôneas.
Abordagem Incremental e Abordagem Incremental e 
IterativaIterativa
 Divide o projeto de desenvolvimento em Divide o projeto de desenvolvimento em 
ciclos;ciclos;
 Cada ciclo considera um subCada ciclo considera um sub--conjunto de conjunto de 
requisitos;requisitos;
 No ciclo seguinte, um outro subNo ciclo seguinte, um outro sub--conjunto de conjunto de 
requisitos requisitos éé considerado, produzindo um considerado, produzindo um 
novo incremento do sistema, contendo novo incrementodo sistema, contendo 
extensões e refinamentos sobre o sistema extensões e refinamentos sobre o sistema 
anterior.anterior.
Abordagem Incremental e Abordagem Incremental e 
IterativaIterativa
 Esta abordagem somente Esta abordagem somente éé posspossíível se vel se 
existir um mecanismo para dividir os existir um mecanismo para dividir os 
requisitos do sistema em partes, alocando requisitos do sistema em partes, alocando 
cada parte a um ciclo de desenvolvimento;cada parte a um ciclo de desenvolvimento;
 A alocaA alocaçção ão éé realizada em funrealizada em funçção da ão da 
prioridade (importância para o cliente) e o prioridade (importância para o cliente) e o 
risco do requisito (os requisitos que risco do requisito (os requisitos que 
apresentam risco maior);apresentam risco maior);
Levantamento de RequisitosLevantamento de Requisitos
 Nesta etapa, o engenheiro de software busca Nesta etapa, o engenheiro de software busca 
compreender as necessidades do usucompreender as necessidades do usuáário e o rio e o 
que ele deseja que o sistema a ser que ele deseja que o sistema a ser 
desenvolvido realize.desenvolvido realize.
 Esta etapa Esta etapa éé realizada principalmente por realizada principalmente por 
meio de entrevistas com os clientes.meio de entrevistas com os clientes.
Levantamento de RequisitosLevantamento de Requisitos
 Durante as entrevistas o engenheiro deve Durante as entrevistas o engenheiro deve 
auxiliar o cliente a definir quais auxiliar o cliente a definir quais 
informainformaçções deverão ser produzidas, quais ões deverão ser produzidas, quais 
informainformaçções deverão ser fornecidas e qual o ões deverão ser fornecidas e qual o 
nníível de desempenho exigido do software.vel de desempenho exigido do software.
 Principal problema: ComunicaPrincipal problema: Comunicaççãoão
Levantamento de RequisitosLevantamento de Requisitos
 Na maioria das vezes os usuNa maioria das vezes os usuáários não têm rios não têm 
realmente certeza do que querem e não realmente certeza do que querem e não 
conseguem enxergar a real capacidade do conseguem enxergar a real capacidade do 
software. software. 
 Em geral os engenheiros de software Em geral os engenheiros de software 
precisam sugerir muitas caracterprecisam sugerir muitas caracteríísticas e sticas e 
funfunçções do sistema que o cliente não sabia ões do sistema que o cliente não sabia 
como formular ou sequer havia imaginado. como formular ou sequer havia imaginado. 
Levantamento de RequisitosLevantamento de Requisitos
 Na realidade, muitas vezes, os engenheiros Na realidade, muitas vezes, os engenheiros 
de software precisam reestruturar a maneira de software precisam reestruturar a maneira 
como as informacomo as informaçções são geridas pela ões são geridas pela 
empresa e apresentar maneiras de combinempresa e apresentar maneiras de combináá--
las e apresentlas e apresentáá--las de forma a serem melhor las de forma a serem melhor 
aproveitadas.aproveitadas.
 Em muitos casos Em muitos casos éé realmente isso que os realmente isso que os 
usuusuáários esperam dos engenheiros de rios esperam dos engenheiros de 
software, em outros, no entanto, encontram software, em outros, no entanto, encontram 
fortes resistências.fortes resistências.
AnAnáálise de Requisitoslise de Requisitos
 Examinar os requisitos enunciados pelos Examinar os requisitos enunciados pelos 
usuusuáários;rios;
 Verificar se estes foram especificados Verificar se estes foram especificados 
corretamente e se foram realmente corretamente e se foram realmente 
compreendidos;compreendidos;
 Determinar as reais necessidades do Determinar as reais necessidades do 
sistema;sistema;
 Como saber se as necessidades dos usuComo saber se as necessidades dos usuáários rios 
foram realmente compreendidas? foram realmente compreendidas? 
AnAnáálise de Requisitoslise de Requisitos
 O engenheiro de software deve determinar: O engenheiro de software deve determinar: 
 Se as necessidades do usuSe as necessidades do usuáário foram rio foram 
entendidas corretamente;entendidas corretamente;
 Se algum tSe algum tóópico deixou de ser abordado; pico deixou de ser abordado; 
 Se algum item foi especificado Se algum item foi especificado 
incorretamente;incorretamente;
 Se algum conceito precisa ser melhor Se algum conceito precisa ser melhor 
explicado. explicado. 
AnAnáálise de Requisitoslise de Requisitos
 Durante a AnDurante a Anáálise de Requisitos, uma lise de Requisitos, uma 
linguagem de modelagem auxilia a levantar linguagem de modelagem auxilia a levantar 
questões que não foram concebidas durante questões que não foram concebidas durante 
as entrevistas iniciais. as entrevistas iniciais. 
 Estas devem ser sanadas o quanto antes, Estas devem ser sanadas o quanto antes, 
para que o software não tenha que ser para que o software não tenha que ser 
modificado quando seu desenvolvimento jmodificado quando seu desenvolvimento jáá
estiver em andamento. estiver em andamento. 
PrototipaPrototipaççãoão
 TTéécnica bastante popular e de fcnica bastante popular e de fáácil cil 
aplicaaplicaçção;ão;
 Consiste em desenvolver rapidamente um Consiste em desenvolver rapidamente um 
““esboesboççoo”” do que seria o sistema quando este do que seria o sistema quando este 
estivesse finalizado. estivesse finalizado. 
PrototipaPrototipaççãoão
 Um protUm protóótipo normalmente apresenta pouco tipo normalmente apresenta pouco 
mais do que a interface do sistema, mais do que a interface do sistema, 
ilustrando como as informailustrando como as informaçções seriam ões seriam 
inseridas e recuperadas no mesmo e inseridas e recuperadas no mesmo e 
apresentando alguns exemplos com dados apresentando alguns exemplos com dados 
fictfictíícios de quais seriam os resultados cios de quais seriam os resultados 
apresentados pelo software, principalmente apresentados pelo software, principalmente 
em forma de relatem forma de relatóórios. rios. 
PrototipaPrototipaççãoão
 A utilizaA utilizaçção de um protão de um protóótipo pode assim tipo pode assim 
evitar que, apevitar que, apóós meses ou mesmo anos de s meses ou mesmo anos de 
desenvolvimento, descubradesenvolvimento, descubra--se ao implantar se ao implantar 
o sistema, que o software não atende o sistema, que o software não atende 
completamente as necessidades do cliente completamente as necessidades do cliente 
devido principalmente a falhas de devido principalmente a falhas de 
comunicacomunicaçção.ão.
PrototipaPrototipaççãoão
 Hoje em dia podeHoje em dia pode--se desenvolver protse desenvolver protóótipos tipos 
com relativa rapidez e facilidade por meio com relativa rapidez e facilidade por meio 
do uso de ferramentas RAD (Rapid do uso de ferramentas RAD (Rapid 
Application Development Application Development ––
Desenvolvimento RDesenvolvimento Ráápido de Aplicapido de Aplicaçções), ões), 
como a fornecida pelo IDE NetBeans.como a fornecida pelo IDE NetBeans.
PrototipaPrototipaççãoão
 As ferramentas RAD permitem a criaAs ferramentas RAD permitem a criaçção de ão de 
formulformuláários e a inserrios e a inserçção de componentes ão de componentes 
nos mesmos de uma forma muito simples, nos mesmos de uma forma muito simples, 
rráápida e fpida e fáácil, bastando ao usucil, bastando ao usuáário rio 
selecionar o componente (botões, caixas de selecionar o componente (botões, caixas de 
texto, labels, etc.), em uma barra de texto, labels, etc.), em uma barra de 
ferramentas e clicar com o mouse sobre o ferramentas e clicar com o mouse sobre o 
formulformuláário. rio. 
PrototipaPrototipaççãoão
 Estas ferramentas permitem ao usuEstas ferramentas permitem ao usuáário rio 
mudar a posimudar a posiçção dos componentes apão dos componentes apóós s 
terem sido colocados no formulterem sido colocados no formuláário rio 
simplesmente selecionando o componente simplesmente selecionando o componente 
com o mouse e o arrastando para a posicom o mouse e oarrastando para a posiçção ão 
desejada. desejada. 
PrototipaPrototipaççãoão
 Assim, depois de determinar quais as Assim, depois de determinar quais as 
modificamodificaçções necessões necessáárias ao sistema, aprias ao sistema, apóós o s o 
protprotóótipo ter sido apresentado aos usutipo ter sido apresentado aos usuáários, rios, 
podepode--se modificar a interface de acordo com se modificar a interface de acordo com 
as novas especificaas novas especificaçções e apresentões e apresentáá--lo lo 
novamente ao cliente de maneira bastante novamente ao cliente de maneira bastante 
rráápida.pida.
PrototipaPrototipaççãoão
 A etapa de AnA etapa de Anáálise de Requisitos deve lise de Requisitos deve 
obrigatoriamente produzir um protobrigatoriamente produzir um protóótipo tipo 
para demonstrar como se apresentarpara demonstrar como se apresentaráá e e 
comportarcomportaráá o sistema em essência, bem o sistema em essência, bem 
como quais informacomo quais informaçções deverão ser ões deverão ser 
inseridas no sistema e que tipo de inseridas no sistema e que tipo de 
informainformaçções deverão ser fornecidas pelo ões deverão ser fornecidas pelo 
software. software. 
PrototipaPrototipaççãoão
 A maioria das dA maioria das dúúvidas e erros de vidas e erros de 
especificaespecificaçção podem ser sanadas, devido ao ão podem ser sanadas, devido ao 
fato de um protfato de um protóótipo demonstrar: tipo demonstrar: 
 Como funcionarComo funcionaráá o sistema depois de o sistema depois de 
concluconcluíído;do;
 Como serComo seráá sua interface;sua interface;
 De que maneira os usuDe que maneira os usuáários interagirão com rios interagirão com 
o mesmo;o mesmo;
 Quais relatQuais relatóórios serão fornecidos;rios serão fornecidos;
ProjetoProjeto
 Determina como o sistema funcionarDetermina como o sistema funcionaráá para para 
atender aos requisitos de acordo com os atender aos requisitos de acordo com os 
recursos tecnolrecursos tecnolóógicos existentes;gicos existentes;
 Considera os aspectos fConsidera os aspectos fíísicos e dependentes sicos e dependentes 
de implementade implementaçção;ão;
 AplicaAplicaçção de restrião de restriçções de tecnologia;ões de tecnologia;
ProjetoProjeto
 Aspectos a serem considerados:Aspectos a serem considerados:
Linguagem de ProgramaLinguagem de Programaçção a ser utilizada;ão a ser utilizada;
Sistema Gerenciador de Banco de Dados;Sistema Gerenciador de Banco de Dados;
Padrão de interface grPadrão de interface grááfica;fica;
Arquitetura do sistema Arquitetura do sistema –– Principal fase de Principal fase de 
modelagem do software.modelagem do software.
ImplementaImplementaççãoão
 CodificaCodificaçção do sistema propriamente dita;ão do sistema propriamente dita;
 TraduTraduçção da modelagem definida na fase de ão da modelagem definida na fase de 
projeto em linhas de cprojeto em linhas de cóódigo atravdigo atravéés de uma s de uma 
linguagem de programalinguagem de programaçção.ão.
TestesTestes
 Etapa em que o software deve ser testado Etapa em que o software deve ser testado 
exaustivamente para determinar se estexaustivamente para determinar se estáá de de 
acordo com as especificaacordo com as especificaçções do usuões do usuáário e rio e 
se estse estáá funcionando corretamente;funcionando corretamente;
 Em sistemas dos quais dependem vidas Em sistemas dos quais dependem vidas 
humanas (controle de aeroportos, humanas (controle de aeroportos, 
monitoramonitoraçção de reatores nucleares), os testes ão de reatores nucleares), os testes 
ocupam de 3 a 5 vezes mais tempo que ocupam de 3 a 5 vezes mais tempo que 
todas as outras etapas.todas as outras etapas.
O problema do programador O problema do programador 
testar o prtestar o próóprio softwareprio software
 A atividade de teste A atividade de teste éé o processo de o processo de 
executar um programa com a intenexecutar um programa com a intençção de ão de 
descobrir um erro;descobrir um erro;
 Um bom caso de teste Um bom caso de teste éé aquele que tem uma aquele que tem uma 
boa probabilidade de revelar um erro ainda boa probabilidade de revelar um erro ainda 
não descoberto;não descoberto;
 Um teste bem sucedido Um teste bem sucedido éé aquele que revela aquele que revela 
um erro ainda não descoberto;um erro ainda não descoberto;
 Grupo independente de teste.Grupo independente de teste.
TestesTestes
 FunFunçções incorretas ou ausentes;ões incorretas ou ausentes;
 Erros de interface;Erros de interface;
 Erros nas estruturas de dados ou no acesso a Erros nas estruturas de dados ou no acesso a 
bancos de dados externos;bancos de dados externos;
 Consistências relacionais;Consistências relacionais;
 ValidaValidaçções;ões;
 Erros de desempenho;Erros de desempenho;
 Erros de iniciaErros de iniciaçção e tão e téérmino;rmino;
 Erros de SeguranErros de Segurançça;a;
Testes Testes -- EstratEstratéégiagia
 Teste de Unidade Teste de Unidade –– Cada mCada móódulo dulo éé testado testado 
individualmente;individualmente;
 Teste de Integridade Teste de Integridade –– Se estSe estáá de acordo de acordo 
com o projeto e se os mcom o projeto e se os móódulos funcionam dulos funcionam 
unidos entre si;unidos entre si;
 Teste de ValidaTeste de Validaçção ão –– ComparaComparaçção do que o ão do que o 
software faz com o que foi requerido pelo software faz com o que foi requerido pelo 
cliente;cliente;
Testes Testes -- EstratEstratéégiagia
 Teste de SistemaTeste de Sistema
Teste de RecuperaTeste de Recuperaçção ão –– Testa a Testa a 
capacidade do sistema seguir capacidade do sistema seguir 
funcionando apfuncionando apóós uma falha;s uma falha;
Teste de SeguranTeste de Segurançça a –– Verifica se os Verifica se os 
mecanismos de protemecanismos de proteçção realmente ão realmente 
protegerão o sistema;protegerão o sistema;
Testes Testes -- EstratEstratéégiagia
 Teste de SistemaTeste de Sistema
Teste de Stress Teste de Stress –– Executa o sistema de Executa o sistema de 
uma forma que exija recursos em uma forma que exija recursos em 
quantidade, freqquantidade, freqüüência ou volumes ência ou volumes 
anormais;anormais;
Teste de Desempenho Teste de Desempenho –– Mede a Mede a 
utilizautilizaçção dos recursos pelo sistema para ão dos recursos pelo sistema para 
descobrir situadescobrir situaçções que levam ões que levam àà
degradadegradaçção e possão e possíível falha.vel falha.
Testes de Caixa BrancaTestes de Caixa Branca
 ConhecendoConhecendo--se o funcionamento interno do se o funcionamento interno do 
produto, testes são realizados para garantir produto, testes são realizados para garantir 
que as operaque as operaçções internas tenham um ões internas tenham um 
desempenho de acordo com as desempenho de acordo com as 
especificaespecificaçções;ões;
Testes de Caixa BrancaTestes de Caixa Branca
 BaseiaBaseia--se em um minucioso exame dos se em um minucioso exame dos 
detalhes procedimentais. Os caminhos detalhes procedimentais. Os caminhos 
llóógicos atravgicos atravéés do software são testados s do software são testados 
pondo pondo àà prova conjuntos especprova conjuntos especííficos de ficos de 
condicondiçções ou laões ou laçços.os.
Testes de Caixa PretaTestes de Caixa Preta
 ConhecendoConhecendo--se a funse a funçção especão especíífica que um fica que um 
determinado produto deve executar, testes determinado produto deve executar, testes 
podem ser realizados para demonstrar que podem ser realizados para demonstrar que 
cada funcada funçção ão éé totalmente operacional.totalmente operacional.
ImplantaImplantaççãoão
 InstalaInstalaçção do software no ambiente do ão do software no ambiente do 
usuusuáário;rio;
 ElaboraElaboraçção dos manuais do sistema;ão dos manuais do sistema;
 Treinamento dos usuTreinamento dos usuáários;rios;
 PossPossíível conversão de dados prvel conversão de dados préé--existentes.existentes.
Fatores que Influenciam a Fatores que Influenciama 
Qualidade de SoftwareQualidade de Software
 Requisitos de SoftwareRequisitos de Software
 Prazos e Custos;Prazos e Custos;
 Manutenibilidade;Manutenibilidade;
 Reusabilidade;Reusabilidade;
 DocumentaDocumentaçção;ão;
Qualidade de SoftwareQualidade de Software
com Relacom Relaçção ão àà RequisitosRequisitos
 Os requisitos são a base a partir da qual a Os requisitos são a base a partir da qual a 
qualidade de um software qualidade de um software éé medida.medida.
 A falta de conformidade aos requisitos A falta de conformidade aos requisitos 
significa falta de qualidade.significa falta de qualidade.
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 Como determinar o prazo real de entrega de Como determinar o prazo real de entrega de 
um software? um software? 
 Quantos profissionais deverão trabalhar no Quantos profissionais deverão trabalhar no 
projeto? projeto? 
 Qual serQual seráá o custo total de desenvolvimento? o custo total de desenvolvimento? 
 Qual deverQual deveráá ser o valor estipulado para ser o valor estipulado para 
produzir o sistema? produzir o sistema? 
 Como determinar a real complexidade de Como determinar a real complexidade de 
desenvolvimento do sistema?desenvolvimento do sistema?
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 A estimativa de tempo A estimativa de tempo éé realmente um realmente um 
ttóópico extremamente complexo da pico extremamente complexo da 
Engenharia de Software;Engenharia de Software;
 Por melhor modelado que um sistema tenha Por melhor modelado que um sistema tenha 
sido, ainda assim fica difsido, ainda assim fica difíícil determinar os cil determinar os 
prazos;prazos;
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 Uma boa modelagem ajuda a determinar a Uma boa modelagem ajuda a determinar a 
complexidade de desenvolvimento do complexidade de desenvolvimento do 
sistema e isso por sua vez ajuda a sistema e isso por sua vez ajuda a 
determinar prazos;determinar prazos;
 No entanto, No entanto, éé preciso possuir diversos preciso possuir diversos 
sistemas jsistemas jáá desenvolvidos e bem desenvolvidos e bem 
documentados, com ndocumentados, com nííveis de dificuldade e veis de dificuldade e 
caractercaracteríísticas semelhantes ao software que sticas semelhantes ao software que 
estestáá para ser construpara ser construíído, para determinar do, para determinar 
com maior exatidão os prazos de entrega.com maior exatidão os prazos de entrega.
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 A documentaA documentaçção deve possuir registro das ão deve possuir registro das 
datas de indatas de iníício e tcio e téérmino dos projetos rmino dos projetos 
concluconcluíídos anteriormente, bem como o dos anteriormente, bem como o 
custo real de desenvolvimento que estes custo real de desenvolvimento que estes 
projetos acarretaram; projetos acarretaram; 
 O tempo de desenvolvimento influencia O tempo de desenvolvimento influencia 
diretamente o custo de desenvolvimento do diretamente o custo de desenvolvimento do 
sistema e logicamente o valor a ser pedido sistema e logicamente o valor a ser pedido 
pelo software. pelo software. 
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 Se a estimativa de prazo estiver errada, cada Se a estimativa de prazo estiver errada, cada 
dia a mais de desenvolvimento do projeto dia a mais de desenvolvimento do projeto 
acarretaracarretaráá prejuprejuíízos para a empresa que zos para a empresa que 
desenvolve o sistema, decorrentes, por desenvolve o sistema, decorrentes, por 
exemplo:exemplo:
 De pagamento de salDe pagamento de saláários aos profissionais rios aos profissionais 
envolvidos no projeto, que não haviam sido envolvidos no projeto, que não haviam sido 
previstos;previstos;
 Desgaste dos equipamentos utilizados;Desgaste dos equipamentos utilizados;
Qualidade de SoftwareQualidade de Software
Prazos e CustosPrazos e Custos
 Manter diversos profissionais ocupados em Manter diversos profissionais ocupados em 
projetos que jprojetos que jáá deveriam estar concludeveriam estar concluíídos dos 
deixando de trabalhar em novos projetos;deixando de trabalhar em novos projetos;
 InsatisfaInsatisfaçção dos clientes por não receberem ão dos clientes por não receberem 
o produto no prazo estimado.o produto no prazo estimado.
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 Alguns autores afirmam que a manutenAlguns autores afirmam que a manutençção ão 
de um software pode representar de 40 a de um software pode representar de 40 a 
60% do custo total do projeto.60% do custo total do projeto.
 Causas:Causas:
Erros de implementaErros de implementaçção;ão;
Desejos de melhorias do usuDesejos de melhorias do usuáário;rio;
MudanMudançças estratas estratéégicas da empresa;gicas da empresa;
MudanMudançças em leis, alas em leis, alííquotas, impostos. quotas, impostos. 
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 Na maioria dos casos a manutenNa maioria dos casos a manutençção de um ão de um 
software software éé inevitinevitáável, por mais bem vel, por mais bem 
modelado que esteja.modelado que esteja.
 As necessidades de uma empresa são As necessidades de uma empresa são 
dinâmicas e elas mudam constantemente, o dinâmicas e elas mudam constantemente, o 
que faz surgir novas necessidades que não que faz surgir novas necessidades que não 
existiam na existiam na éépoca em que o software foi poca em que o software foi 
projetado.projetado.
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 A modelagem não serve unicamente para A modelagem não serve unicamente para 
diminuir a necessidade de futuras diminuir a necessidade de futuras 
manutenmanutençções, mas tambões, mas tambéém para facilitar a m para facilitar a 
compreensão do sistema por quem tiver que compreensão do sistema por quem tiver que 
mantêmantê--lo;lo;
 Em geral a manutenEm geral a manutençção de um sistema ão de um sistema éé
considerada uma tarefa ingrata pelos considerada uma tarefa ingrata pelos 
profissionais de desenvolvimento;profissionais de desenvolvimento;
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 Normalmente exigem que o profissional Normalmente exigem que o profissional 
despenda grandes esfordespenda grandes esforçços para os para 
compreender ccompreender cóódigos escritos por outros digos escritos por outros 
profissionais com estilos de profissionais com estilos de 
desenvolvimento diferentes e que desenvolvimento diferentes e que 
normalmente não se encontram mais na normalmente não se encontram mais na 
empresa. empresa. 
 São os chamados São os chamados ““ccóódigos aliendigos alieníígenasgenas””. . 
Uma variaUma variaçção disso são os ão disso são os ““ccóódigos digos 
legadoslegados””. . 
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 ÉÉ extremamente comum que, apextremamente comum que, apóós manter s manter 
um software, outros mum software, outros móódulos do sistema dulos do sistema 
que antes funcionavam perfeitamente que antes funcionavam perfeitamente 
passem a apresentar erros ou simplesmente passem a apresentar erros ou simplesmente 
deixem de funcionar, são os chamados deixem de funcionar, são os chamados 
““efeitos colateraisefeitos colaterais”” da manutenda manutençção. ão. 
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 Uma modelagem correta aliada a uma Uma modelagem correta aliada a uma 
documentadocumentaçção complementar bastante ão complementar bastante 
profunda e completa de um sistema de profunda e completa de um sistema de 
informainformaçção torna mais rão torna mais ráápido o processo de pido o processo de 
manutenmanutençção e impede que erros sejam ão e impede que erros sejam 
cometidosdurante a mesmo;cometidos durante a mesmo;
Qualidade de SoftwareQualidade de Software
ManutenibilidadeManutenibilidade
 Qualquer manutenQualquer manutençção que precisar ser ão que precisar ser 
operada em um sistema, deve ser tamboperada em um sistema, deve ser tambéém m 
modelada e documentada, para não modelada e documentada, para não 
desatualizar a documentadesatualizar a documentaçção do sistema e ão do sistema e 
prejudicar futuras manutenprejudicar futuras manutençções. ões. 
Qualidade de SoftwareQualidade de Software
ReusabilidadeReusabilidade
 O software precisa ser modelado e O software precisa ser modelado e 
desenvolvido de maneira que suas rotinas desenvolvido de maneira que suas rotinas 
possam ser reaproveitados em projetos possam ser reaproveitados em projetos 
futuros;futuros;
 A modelagem e documentaA modelagem e documentaçção de um ão de um 
software permitem encontrar algoritmos, software permitem encontrar algoritmos, 
rotinas e mrotinas e móódulos com facilidade, aldulos com facilidade, aléém de m de 
facilitar sua compreensão.facilitar sua compreensão.
Qualidade de SoftwareQualidade de Software
ReusabilidadeReusabilidade
 Onde estão as rotinas? Onde estão as rotinas? 
 Para que foram utilizadas? Para que foram utilizadas? 
 Em que projetos estão documentadas? Em que projetos estão documentadas? 
 Elas são adequadas ao software atualmente Elas são adequadas ao software atualmente 
desenvolvido? desenvolvido? 
 Qual o nQual o níível necessvel necessáário de adaptario de adaptaçção das ão das 
rotinas para que estas possam ser utilizadas rotinas para que estas possam ser utilizadas 
no sistema atual?no sistema atual?
Qualidade de SoftwareQualidade de Software
DocumentaDocumentaççãoão
 Como a empresa pode afirmar se estComo a empresa pode afirmar se estáá
evoluindo ou não? evoluindo ou não? 
 O processo de desenvolvimento tornouO processo de desenvolvimento tornou--se se 
mais mais áágil? gil? 
 As metodologias atualmente adotadas são As metodologias atualmente adotadas são 
superiores superiores ààs prs prááticas aplicadas ticas aplicadas 
anteriormente? anteriormente? 
 A qualidade do software produzido estA qualidade do software produzido estáá
melhorando? melhorando? 
Qualidade de SoftwareQualidade de Software
DocumentaDocumentaççãoão
 A empresa necessita de um registro A empresa necessita de um registro 
detalhado de cada um de seus sistemas jdetalhado de cada um de seus sistemas jáá
desenvolvidos para determinar:desenvolvidos para determinar:
 A mA méédia de manutendia de manutençções que um sistema ões que um sistema 
sofre normalmente dentro de um sofre normalmente dentro de um 
determinado perdeterminado perííodo de tempo;odo de tempo;
 Qual a mQual a méédia de custo de modelagem; dia de custo de modelagem; 
 Qual a mQual a méédia de custo de desenvolvimento;dia de custo de desenvolvimento;
Qualidade de SoftwareQualidade de Software
DocumentaDocumentaççãoão
 Qual a mQual a méédia de tempo despendido atdia de tempo despendido atéé a a 
finalizafinalizaçção do projeto;ão do projeto;
 Quantos profissionais foi necessQuantos profissionais foi necessáário rio 
envolver no projeto;envolver no projeto;
 Estas informaEstas informaçções são computadas nos ões são computadas nos 
ororççamentos de desenvolvimento de novos amentos de desenvolvimento de novos 
softwares e são de grande auxsoftwares e são de grande auxíílio no lio no 
momento de determinar prazos e custos momento de determinar prazos e custos 
mais prmais próóximos da realidade.ximos da realidade.
Engenharia de RequisitosEngenharia de Requisitos
 ““EngenhariaEngenharia de Requisitos de Requisitos éé o ramo da o ramo da 
engenharia de software que se dedica a engenharia de software que se dedica a 
determinar os objetivos do mundo real, as determinar os objetivos do mundo real, as 
funfunçções e as restriões e as restriçções do software, bem ões do software, bem 
como em determinar o relacionamento como em determinar o relacionamento 
destes fatores para especificadestes fatores para especificaçções precisas ões precisas 
do comportamento do software e suas do comportamento do software e suas 
evoluevoluçções ao longo do tempo e entre as ões ao longo do tempo e entre as 
famfamíílias de lias de softwaresoftware”” ZaveZave (1997).(1997).
Engenharia de RequisitosEngenharia de Requisitos
 JJáá segundo segundo BerenbachBerenbach (2009), a engenharia (2009), a engenharia 
de requisitos envolve todas as atividades do de requisitos envolve todas as atividades do 
ciclo de vida devotadas ciclo de vida devotadas àà identificaidentificaçção de ão de 
requisitos de usurequisitos de usuáário, anrio, anáálise dos requisitos lise dos requisitos 
para derivar requisitos adicionais, para derivar requisitos adicionais, 
documentadocumentaçção dos requisitos como uma ão dos requisitos como uma 
especificaespecificaçção e validaão e validaçção dos requisitos ão dos requisitos 
documentados de acordo com as documentados de acordo com as 
necessidades do usunecessidades do usuáário, bem como os rio, bem como os 
processos que suportam estas atividades.processos que suportam estas atividades.
Engenharia de RequisitosEngenharia de Requisitos
 Sommerville (2003) define Engenharia de Sommerville (2003) define Engenharia de 
Requisitos como Requisitos como ““O conjunto de tO conjunto de téécnicas cnicas 
empregadas para levantar, detalhar, empregadas para levantar, detalhar, 
documentar e validar os requisitos de um documentar e validar os requisitos de um 
produto forma a Engenharia de Requisitosproduto forma a Engenharia de Requisitos””;;
Engenharia de RequisitosEngenharia de Requisitos
 XiaoXiao (2003), declara que por meio da (2003), declara que por meio da 
compreensão das crencompreensão das crençças dos interessados as dos interessados 
((stakeholdersstakeholders), a engenharia de requisitos ), a engenharia de requisitos 
especifica um problema a ser solucionado, especifica um problema a ser solucionado, 
identifica os limites do sistema, analisa identifica os limites do sistema, analisa 
propriedades do ambiente e caracteriza os propriedades do ambiente e caracteriza os 
comportamentos do software resultante;comportamentos do software resultante;
 As atividadesAs atividades centrais da engenharia de centrais da engenharia de 
requisitos são:requisitos são:
Engenharia de RequisitosEngenharia de Requisitos
 ExtraExtraçção (ão (elicitaelicitaççãoão) de requisitos, onde ) de requisitos, onde 
procuraprocura--se determinar o problema a ser se determinar o problema a ser 
solucionado e identificar os limites do solucionado e identificar os limites do 
sistema;sistema;
 Análise e modelagem de requisitos, onde 
constrói-se descrições abstratas passíveis de 
interpretação;
Engenharia de RequisitosEngenharia de Requisitos
 ComunicaComunicaçção de requisitos, onde os ão de requisitos, onde os 
requisitos são comunicados entre os requisitos são comunicados entre os 
interessados (interessados (stakeholdersstakeholders););
 A forma como os requisitos são A forma como os requisitos são 
documentados desempenha um papel documentados desempenha um papel 
importante em garantir que estes podem ser importante em garantir que estes podem ser 
lidos, analisados, relidos, analisados, re--escritos e validados.escritos e validados.
Engenharia de RequisitosEngenharia de Requisitos
 ConcordânciaConcordância de requisitos, onde tentade requisitos, onde tenta--se se 
resolver conflitos entre os interessados, resolver conflitos entre os interessados, 
quando estes têm objetivos quando estes têm objetivos divergentes;divergentes;
 EvoluEvoluççãoão de requisitos, onde de requisitos, onde éé necessnecessáário rio 
gerenciar a documentagerenciar a documentaçção dos requisitos ão dos requisitos 
quando estes mudam em novas versões ou quando estes mudam em novas versões ou 
mesmo na versão atual, quando o impacto mesmo na versão atual, quandoo impacto 
destas mudandestas mudançças e o risco ao projeto devem as e o risco ao projeto devem 
ser monitoradas e controladas.ser monitoradas e controladas.
Engenharia de RequisitosEngenharia de Requisitos
 Segundo Segundo BerenbachBerenbach (2009), estudos (2009), estudos 
indicam que cerca de metade dos fatores indicam que cerca de metade dos fatores 
associados com o sucesso de projetos estão associados com o sucesso de projetos estão 
relacionados aos requisitos e que o sucesso relacionados aos requisitos e que o sucesso 
de um projeto de software estde um projeto de software estáá diretamente diretamente 
ligado ligado àà qualidade dos mesmos;qualidade dos mesmos;
Engenharia de RequisitosEngenharia de Requisitos
 Isto Isto éé corroborado por corroborado por HullHull (2005) e (2005) e 
Pressman (1995) que afirmam que a Pressman (1995) que afirmam que a 
definidefiniçção incorreta dos requisitos do sistema ão incorreta dos requisitos do sistema 
éé um dos principais fatores para a falha de um dos principais fatores para a falha de 
um projeto;um projeto;
 JJáá segundo segundo RegnelRegnel (1999), a (1999), a elicitaelicitaççãoão, , 
ananáálise e documentalise e documentaçção de requisitos em ão de requisitos em 
sistemas complexos sistemas complexos éé uma tarefa crucial e uma tarefa crucial e 
nãonão--trivial. trivial. 
Engenharia de RequisitosEngenharia de Requisitos
 E, segundo E, segundo SommervilleSommerville (2003), casos de (2003), casos de 
uso são de interesse especial na engenharia uso são de interesse especial na engenharia 
de requisitos, uma vez que se mostraram de requisitos, uma vez que se mostraram 
valiosos para valiosos para elicitarelicitar, documentar e analisar , documentar e analisar 
requisitos. requisitos. 
Engenharia de RequisitosEngenharia de Requisitos
 VVáários autores como Rodriguez (2011), rios autores como Rodriguez (2011), 
BerenbachBerenbach (2009), (2009), SommervilleSommerville (2003), (2003), 
PapasimeonPapasimeon (2003), Bezerra (2002), Melo (2003), Bezerra (2002), Melo 
(2002), (2002), BoochBooch (2000) e (2000) e RegnelRegnel (1999), (1999), 
sugerem a aplicasugerem a aplicaçção do diagrama de casos ão do diagrama de casos 
de uso da UML para a modelagem de de uso da UML para a modelagem de 
requisitos.requisitos.
Engenharia de RequisitosEngenharia de Requisitos
 AlAléém disso, segundo m disso, segundo RegnelRegnel (1999), casos (1999), casos 
de uso tambde uso tambéém permitem a m permitem a rastreabilidaderastreabilidade
de requisitos nas fases de projeto, de requisitos nas fases de projeto, 
implementaimplementaçção e verificaão e verificaçção e validaão e validaçção.ão.
 HullHull (2005) afirma que requisitos são a base (2005) afirma que requisitos são a base 
de todo projeto, definindo o que os de todo projeto, definindo o que os 
stakeholdersstakeholders necessitam de um sistema e o necessitam de um sistema e o 
que o sistema deve fazer de forma a que o sistema deve fazer de forma a 
satisfazer esta necessidade. satisfazer esta necessidade. 
Engenharia de RequisitosEngenharia de Requisitos
 HullHull (2005) destaca ainda que requisitos (2005) destaca ainda que requisitos 
formam a base para planejamento de formam a base para planejamento de 
projeto, gerenciamento de risco, teste de projeto, gerenciamento de risco, teste de 
aceitaaceitaçção, ão, tradeofftradeoff (escolha entre op(escolha entre opçções ões 
conflitantes)conflitantes) e controle de mudane controle de mudançça.a.
Engenharia de RequisitosEngenharia de Requisitos
 De De acordo comacordo com BerenbachBerenbach (2009), as (2009), as 
caractercaracteríísticas de um bom requisito são que sticas de um bom requisito são que 
ele seja possele seja possíível, vvel, váálido, lido, unambunambííguoguo, , 
verificverificáável, modificvel, modificáável, consistente, vel, consistente, 
completo e que possa ser completo e que possa ser rastrerastreáávelvel..
Engenharia de RequisitosEngenharia de Requisitos
 O Fluxo de Requisitos reO Fluxo de Requisitos reúúne as atividades ne as atividades 
que visam a obter o enunciado completo, que visam a obter o enunciado completo, 
claro e preciso dos requisitos de um produto claro e preciso dos requisitos de um produto 
de software;de software;
 Esses requisitos devem ser levantados pela Esses requisitos devem ser levantados pela 
equipe do projeto, em conjunto com equipe do projeto, em conjunto com 
representantes do cliente, usurepresentantes do cliente, usuáários chaves e rios chaves e 
outros especialistas da outros especialistas da áárea de aplicarea de aplicaçção ão 
(Stakeholders).(Stakeholders).
Engenharia de RequisitosEngenharia de Requisitos
 O resultado principal do fluxo dos requisitos O resultado principal do fluxo dos requisitos 
éé um documento de Especificaum documento de Especificaçção de ão de 
Requisitos de Software (ERSw);Requisitos de Software (ERSw);
 Requisitos de alta qualidade são claros, Requisitos de alta qualidade são claros, 
completos, não ambcompletos, não ambííguos, implementguos, implementááveis, veis, 
consistentes e testconsistentes e testááveis;veis;
 Os requisitos que não apresentam essas Os requisitos que não apresentam essas 
qualidades são problemqualidades são problemááticos: Eles devem ticos: Eles devem 
ser revistos e renegociados com os clientes ser revistos e renegociados com os clientes 
e usue usuáários.rios.
Engenharia de RequisitosEngenharia de Requisitos
 As caracterAs caracteríísticas que devem estar contidas sticas que devem estar contidas 
na Especificana Especificaçção dos Requisitos do ão dos Requisitos do 
Software incluem:Software incluem:
 Funcionalidades: O que o software deverFuncionalidades: O que o software deveráá
fazer;fazer;
 Interfaces externas: Como o software Interfaces externas: Como o software 
interage com as pessoas, com o hardware do interage com as pessoas, com o hardware do 
sistema, com outros sistemas e com outros sistema, com outros sistemas e com outros 
produtos?produtos?
Engenharia de RequisitosEngenharia de Requisitos
 Desempenho: Qual a velocidade de Desempenho: Qual a velocidade de 
processamento, o tempo de resposta e processamento, o tempo de resposta e 
outros parâmetros de desempenho outros parâmetros de desempenho 
requeridos pela natureza da aplicarequeridos pela natureza da aplicaçção?ão?
 Outros atributos: Quais as consideraOutros atributos: Quais as consideraçções ões 
sobre portabilidade, manutenibilidade e sobre portabilidade, manutenibilidade e 
confiabilidade que devem ser observadas?confiabilidade que devem ser observadas?
Engenharia de RequisitosEngenharia de Requisitos
 RestriRestriçções impostas pela aplicaões impostas pela aplicaçção: Existem ão: Existem 
padrões e outros limites a serem padrões e outros limites a serem 
obedecidos, como linguagem de obedecidos, como linguagem de 
implementaimplementaçção, ambientes de operaão, ambientes de operaçção, ão, 
limites de recursos, etc?limites de recursos, etc?
Engenharia de RequisitosEngenharia de Requisitos
 A especificaA especificaçção dos requisitos do software ão dos requisitos do software 
deve ser escrita por membros da equipe de deve ser escrita por membros da equipe de 
desenvolvimento com a participadesenvolvimento com a participaçção ão 
obrigatobrigatóória de um ou mais usuria de um ou mais usuáários chaves;rios chaves;
 UsuUsuáários chave (stakeholders) são aqueles rios chave (stakeholders) são aqueles 
indicados pelo cliente como pessoa indicados pelo cliente como pessoa 
capacitada a definir requisitos do produto, capacitada a definir requisitos do produto, 
escolhidos entre profissionais experientes escolhidos entre profissionais experientes 
das das ááreas que usarão o produto.reas que usarão o produto.
Engenharia de RequisitosEngenharia de Requisitos
 Os usuOs usuáários chaves devem ser devidamente rios chaves devem ser devidamente 
informados e treinados sobre as tinformados e treinadossobre as téécnicas e cnicas e 
notanotaçções que serão utilizadas no fluxo de ões que serão utilizadas no fluxo de 
requisitos;requisitos;
 Geralmente, nem desenvolvedores nem Geralmente, nem desenvolvedores nem 
clientes ou usuclientes ou usuáários são qualificados para rios são qualificados para 
escrever por si sescrever por si sóós a especificas a especificaçção dos ão dos 
requisitos do software, porque:requisitos do software, porque:
Engenharia de RequisitosEngenharia de Requisitos
 Os clientes nem sempre entendem os Os clientes nem sempre entendem os 
processos de desenvolvimento de software processos de desenvolvimento de software 
em grau suficiente para produzir uma em grau suficiente para produzir uma 
especificaespecificaçção de requisitos de ão de requisitos de 
implementaimplementaçção vião viáável;vel;
 Os desenvolvedores nem sempre entendem Os desenvolvedores nem sempre entendem 
a a áárea de aplicarea de aplicaçção de forma suficiente para ão de forma suficiente para 
produzir uma especificaproduzir uma especificaçção de requisitos ão de requisitos 
satisfatsatisfatóória.ria.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Para servir de base a um produto de boa Para servir de base a um produto de boa 
qualidade, a Especificaqualidade, a Especificaçção de Requisitos ão de Requisitos 
deve satisfazer uma sdeve satisfazer uma séérie de caracterrie de caracteríísticas sticas 
de qualidade;de qualidade;
 Uma EspecificaUma Especificaçção de Requisitos deve ser:ão de Requisitos deve ser:
Correta: Todo requisito presente realmente Correta: Todo requisito presente realmente 
éé um requisito do produto a ser construum requisito do produto a ser construíído;do;
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Precisa: Todo requisito presente possui Precisa: Todo requisito presente possui 
apenas uma apenas uma úúnica interpretanica interpretaçção, aceita tanto ão, aceita tanto 
pelos desenvolvedores quanto pelos pelos desenvolvedores quanto pelos 
usuusuáários chaves;rios chaves;
ModificModificáável: Sua estrutura e estilo vel: Sua estrutura e estilo 
permitem a mudanpermitem a mudançça de qualquer requisito, a de qualquer requisito, 
de maneira fde maneira fáácil, completa e consistente.cil, completa e consistente.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
Completa: Reflete todas as decisões de Completa: Reflete todas as decisões de 
especificaespecificaçção que foram tomadas, não ão que foram tomadas, não 
contendo pendências. Uma Especificacontendo pendências. Uma Especificaçção de ão de 
Requisitos deve:Requisitos deve:
 Conter todos os requisitos significativos Conter todos os requisitos significativos 
relativos a funcionalidade, desempenho, relativos a funcionalidade, desempenho, 
restrirestriçções de desempenho, atributos e ões de desempenho, atributos e 
interfaces externas.interfaces externas.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Definir as respostas do software para todas Definir as respostas do software para todas 
as entradas possas entradas possííveis, vveis, váálidas e invlidas e inváálidas, lidas, 
em todas as situaem todas as situaçções possões possííveis;veis;
 Conter um glossConter um glossáário de todos os termos rio de todos os termos 
ttéécnicos e unidades de medida, assim como cnicos e unidades de medida, assim como 
referências completas a todos os diagramas, referências completas a todos os diagramas, 
figuras e tabelas.figuras e tabelas.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
Consistente: Não hConsistente: Não háá conflitos entre nenhum conflitos entre nenhum 
dos subconjuntos de requisitos presentes. dos subconjuntos de requisitos presentes. 
Existem três tipos comuns de conflitos entre Existem três tipos comuns de conflitos entre 
requisitos:requisitos:
 Conflito entre caracterConflito entre caracteríísticas de objetos do sticas de objetos do 
mundo real como formatos de relatmundo real como formatos de relatóórios, rios, 
cores, padrões de interface;cores, padrões de interface;
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Conflito lConflito lóógico ou temporal entre agico ou temporal entre açções, por ões, por 
exemplo, um requisito diz que a aexemplo, um requisito diz que a açção A ão A 
deve ser realizada antes da B, e outro deve ser realizada antes da B, e outro 
requisito diz o contrrequisito diz o contráário;rio;
 Uso de termos diferentes para designar o Uso de termos diferentes para designar o 
mesmo objeto do mundo real, como mesmo objeto do mundo real, como ““avisoaviso””
e e ““mensagemmensagem””..
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Priorizada: Cada requisito Priorizada: Cada requisito éé classificado de classificado de 
acordo com a sua importância, estabilidade acordo com a sua importância, estabilidade 
e complexidade. e complexidade. 
 A estabilidade estima a probabilidade de A estabilidade estima a probabilidade de 
que o requisito venha a ser alterado no que o requisito venha a ser alterado no 
decorrer do projeto, com base na decorrer do projeto, com base na 
experiência de projetos correlatos. experiência de projetos correlatos. 
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 A priorizaA priorizaçção classifica o requisito de ão classifica o requisito de 
acordo com um dos seguintes graus:acordo com um dos seguintes graus:
 Requisito essencial, sem cujo atendimento o Requisito essencial, sem cujo atendimento o 
produto produto éé inaceitinaceitáável;vel;
 Requisito desejRequisito desejáável, cujo atendimento vel, cujo atendimento 
aumenta o valor do produto, mas cuja aumenta o valor do produto, mas cuja 
ausência pode ser relevada em caso de ausência pode ser relevada em caso de 
necessidade;necessidade;
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Requisito opcional, requisito a ser cumprido Requisito opcional, requisito a ser cumprido 
se houver prazo e orse houver prazo e orççamento, depois de amento, depois de 
atendidos os demais requisitos.atendidos os demais requisitos.
VerificVerificáável: Um requisito vel: Um requisito éé verificverificáável se vel se 
existir um processo finito com custo existir um processo finito com custo 
compensador, que possa ser executado por compensador, que possa ser executado por 
uma pessoa ou muma pessoa ou mááquina, e que mostre a quina, e que mostre a 
conformidade do produto final com o conformidade do produto final com o 
requisito.requisito.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
RastreRastreáável: Permite a fvel: Permite a fáácil determinacil determinaçção ão 
dos antecedentes e das consequências de dos antecedentes e das consequências de 
todos os requisitos. todos os requisitos. 
 Existem dois tipos de Rastreabilidade:Existem dois tipos de Rastreabilidade:
 Rastreabilidade para trRastreabilidade para tráás: deve ser posss: deve ser possíível vel 
localizar a origem de cada requisito.localizar a origem de cada requisito.
Engenharia de RequisitosEngenharia de Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 DeveDeve--se sempre saber por que existe cada se sempre saber por que existe cada 
requisito, e quem ou o que o originou.requisito, e quem ou o que o originou.
 Isso Isso éé importante para que se possa avaliar o importante para que se possa avaliar o 
impacto da mudanimpacto da mudançça daquele requisito, e a daquele requisito, e 
dirimir ddirimir dúúvidas de interpretavidas de interpretaçção.ão.
Engenharia de RequisitosEngenhariade Requisitos
Qualidade dos RequisitosQualidade dos Requisitos
 Rastreabilidade para a frente: Rastreabilidade para a frente: 
 Deve ser possDeve ser possíível localizar quais os vel localizar quais os 
resultados do desenvolvimento que serão resultados do desenvolvimento que serão 
afetados por cada requisito. Isso afetados por cada requisito. Isso éé
importante para garantir que os itens de importante para garantir que os itens de 
ananáálise, desenho, clise, desenho, cóódigo e testes abranjam digo e testes abranjam 
todos os requisitos, e para localizar os itens todos os requisitos, e para localizar os itens 
que serão afetados por uma mudanque serão afetados por uma mudançça nos a nos 
requisitos.requisitos.
Gerenciamento de ProjetosGerenciamento de Projetos
 O gerenciamento de projeto O gerenciamento de projeto éé uma das uma das 
distindistinçções que diferenciam o ões que diferenciam o 
desenvolvimento profissional e o amador;desenvolvimento profissional e o amador;
 Gerentes de software são responsGerentes de software são responsááveis por veis por 
planejar o desenvolvimento do projeto, planejar o desenvolvimento do projeto, 
supervisionando o trabalho para assegurar supervisionando o trabalho para assegurar 
que ele seja realizado em conformidade com que ele seja realizado em conformidade com 
os padrões requeridos;os padrões requeridos;
Gerenciamento de ProjetosGerenciamento de Projetos
 AlAléém de monitorar o progresso para m de monitorar o progresso para 
verificar se o desenvolvimento estverificar se o desenvolvimento estáá dentro dentro 
do prazo e do ordo prazo e do orççamento;amento;
 O bom gerenciamento não O bom gerenciamento não éé uma garantia uma garantia 
absoluta do sucesso do projeto, porabsoluta do sucesso do projeto, poréém o m o 
mau gerenciamento acarreta com certeza mau gerenciamento acarreta com certeza 
atrasos na entrega, aumento do custo oratrasos na entrega, aumento do custo orççado ado 
e inconformidade com os requisitos.e inconformidade com os requisitos.
DiferenDiferençças entre a Engenharia de as entre a Engenharia de 
Software e outras EngenhariasSoftware e outras Engenharias
 O produto O produto éé intangintangíível: Um projeto de vel: Um projeto de 
construconstruçção fão fíísico apresenta seu progresso de sico apresenta seu progresso de 
forma que ele possa ser observado forma que ele possa ser observado 
fisicamente, no entanto um projeto de fisicamente, no entanto um projeto de 
software possui uma abstrasoftware possui uma abstraçção muito maior, ão muito maior, 
sendo difsendo difíícil determinar a evolucil determinar a evoluçção de ão de 
desenvolvimento do software devido a desenvolvimento do software devido a 
incapacidade de medir com precisão qual incapacidade de medir com precisão qual 
serseráá a complexidade do restante.a complexidade do restante.
DiferenDiferençças entre a Engenharia de as entre a Engenharia de 
Software e outras EngenhariasSoftware e outras Engenharias
 Não hNão háá processo de softwareprocesso de software--padrão: Cada padrão: Cada 
novo grande projeto normalmente constitui novo grande projeto normalmente constitui 
um novo desafio, não existindo uma receita um novo desafio, não existindo uma receita 
de bolo de como desenvolvêde bolo de como desenvolvê--lo.lo.
 Constante evoluConstante evoluçção tecnolão tecnolóógica: A gica: A 
constante evoluconstante evoluçção tecnolão tecnolóógica, gica, 
principalmente na principalmente na áárea de software, anula rea de software, anula 
muito da experiência de desenvolvimento muito da experiência de desenvolvimento 
anterior do engenheiro.anterior do engenheiro.
Atividades de GerenciamentoAtividades de Gerenciamento
 O gerente de software O gerente de software éé responsresponsáável por vel por 
todas ou algumas das seguintes atividades:todas ou algumas das seguintes atividades:
 ElaboraElaboraçção de propostas;ão de propostas;
 Planejamento de projetos;Planejamento de projetos;
 Custo do projeto;Custo do projeto;
 Monitoramento e revisões do projeto;Monitoramento e revisões do projeto;
 SeleSeleçção e avaliaão e avaliaçção de pessoal;ão de pessoal;
 ElaboraElaboraçção de relatão de relatóórios e apresentarios e apresentaçções.ões.
ElaboraElaboraçção de Propostasão de Propostas
 ConstituiConstitui--se no primeiro estse no primeiro estáágio de um gio de um 
projeto. projeto. 
 A proposta deve descrever os objetivos do A proposta deve descrever os objetivos do 
projeto e como ele serprojeto e como ele seráá realizado, incluindo realizado, incluindo 
estimativas de custo e prazo, por esse estimativas de custo e prazo, por esse 
motivo deve ser muito bem elaborado.motivo deve ser muito bem elaborado.
Planejamento de ProjetosPlanejamento de Projetos
 Se ocupa em identificar as atividades, os Se ocupa em identificar as atividades, os 
marcos e os documentos a serem produzidos marcos e os documentos a serem produzidos 
em um projeto;em um projeto;
 A estimativa de custos A estimativa de custos éé uma atividade que uma atividade que 
se ocupa em estimar os recursos requeridos se ocupa em estimar os recursos requeridos 
para realizar o projeto.para realizar o projeto.
Monitoramento de ProjetosMonitoramento de Projetos
 ÉÉ uma atividade contuma atividade contíínua. O gerente deve nua. O gerente deve 
acompanhar o andamento do projeto e acompanhar o andamento do projeto e 
comparar os progressos e custos reais com comparar os progressos e custos reais com 
os que foram planejados.os que foram planejados.
 O monitoramento informal pode prever O monitoramento informal pode prever 
problemas em potencial no projeto, problemas em potencial no projeto, 
revelando dificuldades revelando dificuldades àà medida em que medida em que 
elas ocorrem.elas ocorrem.
SeleSeleçção de Pessoalão de Pessoal
 O ideal O ideal éé que uma equipe hque uma equipe háábil com bil com 
experiência esteja disponexperiência esteja disponíível, no entanto vel, no entanto 
nem sempre isso nem sempre isso éé posspossíível, por motivos vel, por motivos 
como:como:
 O orO orççamento do projeto pode não ser amento do projeto pode não ser 
suficiente para contratar profissionais suficiente para contratar profissionais 
experientes;experientes;
 Não existe pessoal experiente disponNão existe pessoal experiente disponíível;vel;
SeleSeleçção de Pessoalão de Pessoal
 A organizaA organizaçção pode querer treinar seu ão pode querer treinar seu 
prpróóprio pessoal, ganhando experiência com prio pessoal, ganhando experiência com 
projetos considerados não tão importantes.projetos considerados não tão importantes.
 Se não houver ao menos alguns Se não houver ao menos alguns 
profissionais experientes muitos erros profissionais experientes muitos erros 
simples podem ocorrer.simples podem ocorrer.
ElaboraElaboraçção de Relatão de Relatóórios e rios e 
ApresentaApresentaççõesões
 Os gerentes devem desenvolver relatOs gerentes devem desenvolver relatóórios rios 
concisos e coerentes que resumam as concisos e coerentes que resumam as 
informainformaçções fundamentais do andamento do ões fundamentais do andamento do 
projeto;projeto;
 Esses relatEsses relatóórios devem ser apresentados rios devem ser apresentados 
durante as revisões de andamento do projeto durante as revisões de andamento do projeto 
aos seus superiores ou aos clientes que aos seus superiores ou aos clientes que 
solicitaram o software.solicitaram o software.
Planejamento de ProjetoPlanejamento de Projeto
 O gerenciamento eficaz de um projeto de O gerenciamento eficaz de um projeto de 
software depende de um planejamento software depende de um planejamento 
acurado do andamento do projeto. acurado do andamento do projeto. 
 O gerente de projeto deve prever os O gerente de projeto deve prever os 
problemas que podem surgir e preparar problemas que podem surgir e preparar 
solusoluçções experimentais para estes ões experimentais para estes 
problemas.problemas.Planejamento de ProjetoPlanejamento de Projeto
 Um plano traUm plano traççado no inado no iníício do projeto deve cio do projeto deve 
ser utilizado como guia para o mesmo;ser utilizado como guia para o mesmo;
 O plano inicial deve ser o melhor possO plano inicial deve ser o melhor possíível, vel, 
em face das informaem face das informaçções disponões disponííveis, ele veis, ele 
deve evoluir deve evoluir àà medida que o projeto seja medida que o projeto seja 
desenvolvido e melhores informadesenvolvido e melhores informaçções se ões se 
tornem dispontornem disponííveis.veis.
Planejamento de ProjetoPlanejamento de Projeto
Outros Tipos de PlanosOutros Tipos de Planos
 Plano de qualidade: Descreve os Plano de qualidade: Descreve os 
procedimentos para teste de qualidade que procedimentos para teste de qualidade que 
serão utilizados em um projeto.serão utilizados em um projeto.
 Plano de validaPlano de validaçção: Descreve a abordagem, ão: Descreve a abordagem, 
os recursos e os mos recursos e os méétodos utilizados para a todos utilizados para a 
validavalidaçção do sistema.ão do sistema.
Planejamento de ProjetoPlanejamento de Projeto
Outros Tipos de PlanosOutros Tipos de Planos
 Plano de gerenciamento de configuraPlano de gerenciamento de configuraçção: ão: 
Descreve os procedimentos de Descreve os procedimentos de 
gerenciamento e as estruturas a serem gerenciamento e as estruturas a serem 
utilizadas;utilizadas;
 Plano de manutenPlano de manutençção: Prevê os requisitos de ão: Prevê os requisitos de 
manutenmanutençção do sistema, os custos de ão do sistema, os custos de 
manutenmanutençção e o esforão e o esforçço necesso necessáário;rio;
Planejamento de ProjetoPlanejamento de Projeto
 Plano de desenvolvimento de equipe: Plano de desenvolvimento de equipe: 
Descreve como as habilidades e a Descreve como as habilidades e a 
experiência dos membros da equipe de experiência dos membros da equipe de 
projeto serão desenvolvidas.projeto serão desenvolvidas.
Planejamento de ProjetoPlanejamento de Projeto
 IniciaInicia--se com uma avaliase com uma avaliaçção das restrião das restriçções ões 
que afetam o projeto, como:que afetam o projeto, como:
 Data de entrega estabelecida;Data de entrega estabelecida;
 Pessoal disponPessoal disponíível;vel;
 OrOrççamento total;amento total;
Planejamento de ProjetoPlanejamento de Projeto
 Essa avaliaEssa avaliaçção ão éé realizada em conjunto com realizada em conjunto com 
uma estimativa dos parâmetros para o uma estimativa dos parâmetros para o 
projeto, como:projeto, como:
 Estrutura do projeto;Estrutura do projeto;
 Tamanho do projeto;Tamanho do projeto;
 Complexidade do projeto;Complexidade do projeto;
 DistribuiDistribuiçção de funão de funçções.ões.
Planejamento de ProjetoPlanejamento de Projeto
 A partir dessas avaliaA partir dessas avaliaçções, os marcos de ões, os marcos de 
progresso e os mprogresso e os móódulos a serem entregues dulos a serem entregues 
são então definidos.são então definidos.
 ApApóós o projeto ter sido iniciado, de tempos s o projeto ter sido iniciado, de tempos 
em tempos o andamento deve ser em tempos o andamento deve ser 
examinado e as possexaminado e as possííveis discrepâncias veis discrepâncias 
observadas, havendo possobservadas, havendo possííveis modificaveis modificaçções ões 
no projeto.no projeto.
Planejamento de ProjetoPlanejamento de Projeto
 Se o projeto estiver atrasado, talvez seja Se o projeto estiver atrasado, talvez seja 
necessnecessáário renegociar com o cliente as rio renegociar com o cliente as 
restrirestriçções do projeto e os mões do projeto e os móódulos a serem dulos a serem 
entregues.entregues.
 Se a negociaSe a negociaçção não for bem sucedida e a ão não for bem sucedida e a 
programaprogramaçção não puder ser cumprida, ão não puder ser cumprida, 
deverdeveráá ser considerada uma revisão tser considerada uma revisão téécnica cnica 
do projeto.do projeto.
Planejamento de ProjetoPlanejamento de Projeto
 Uma revisão tUma revisão téécnica procura encontrar uma cnica procura encontrar uma 
abordagem de desenvolvimento alternativa, abordagem de desenvolvimento alternativa, 
que se limite que se limite ààs restris restriçções do projeto e ões do projeto e 
cumpra os prazos.cumpra os prazos.
 O planejamento do projeto deve ser O planejamento do projeto deve ser 
pessimista, ou seja, problemas ocorrerão. pessimista, ou seja, problemas ocorrerão. 
DeveDeve--se tentar prever todas as possse tentar prever todas as possííveis veis 
eventualidades no plano de projeto para que eventualidades no plano de projeto para que 
as restrias restriçções e os marcos não tenham que ões e os marcos não tenham que 
ser renegociadas.ser renegociadas.
Planejamento de ProjetoPlanejamento de Projeto
 A maioria dos planos de projeto devem A maioria dos planos de projeto devem 
incluir:incluir:
 IntroduIntroduçção: Descreve com brevidade os ão: Descreve com brevidade os 
objetivos do projeto e definir as restriobjetivos do projeto e definir as restriçções ões 
que afetam seu gerenciamento;que afetam seu gerenciamento;
 OrganizaOrganizaçção de projeto: Descreve o modo ão de projeto: Descreve o modo 
como a equipe de desenvolvimento como a equipe de desenvolvimento éé
organizada;organizada;
Planejamento de ProjetoPlanejamento de Projeto
 AnAnáálise de riscos: Descreve os posslise de riscos: Descreve os possííveis veis 
riscos do projeto, a probabilidade destes riscos do projeto, a probabilidade destes 
ocorrerem e as estratocorrerem e as estratéégias para contorngias para contornáá--los.los.
 Requisitos necessRequisitos necessáários de hardware e rios de hardware e 
software: Se houver necessidade de compra software: Se houver necessidade de compra 
de hardware ou software estes devem de hardware ou software estes devem 
obviamente serem computados no obviamente serem computados no 
ororççamento.amento.
Planejamento de ProjetoPlanejamento de Projeto
 Estrutura analEstrutura analíítica: Descreve a divisão do tica: Descreve a divisão do 
trabalho em atividades e identifica os trabalho em atividades e identifica os 
marcos e os mmarcos e os móódulos a serem entregues ao dulos a serem entregues ao 
ttéérmino de cada atividade;rmino de cada atividade;
 ProgramaProgramaçção de projeto: Descreve as ão de projeto: Descreve as 
dependências entre as atividades, o tempo dependências entre as atividades, o tempo 
estimado necessestimado necessáário para atingir cada marco rio para atingir cada marco 
e a alocae a alocaçção de pessoas nas atividades.ão de pessoas nas atividades.
Planejamento de ProjetoPlanejamento de Projeto
 Mecanismos de monitoramento e de Mecanismos de monitoramento e de 
elaboraelaboraçção de relatão de relatóórios: Descreve os rios: Descreve os 
relatrelatóórios de gerenciamento que devem ser rios de gerenciamento que devem ser 
produzidos, quando eles devem ser produzidos, quando eles devem ser 
produzidos e quais mecanismos de produzidos e quais mecanismos de 
monitoramento são utilizados.monitoramento são utilizados.
Marcos e produtos a serem Marcos e produtos a serem 
entreguesentregues
 Um marco Um marco éé o ponto final de uma atividade o ponto final de uma atividade 
de processo de software.de processo de software.
 A cada marco deve haver uma saA cada marco deve haver uma saíída formal, da formal, 
como um relatcomo um relatóório, que possa ser rio, que possa ser 
apresentado para a gerência, podendo ser apresentado para a gerência, podendo ser 
um breve relatum breve relatóório das realizario das realizaçções em uma ões em uma 
atividade de projeto.atividade de projeto.
 Devem representar o final de um estDevem representar o final de um estáágio gio 
distinto e ldistinto e lóógico de um projeto.gico de um projeto.
Marcos e produtos a serem Marcos e produtos a serem 
entreguesentregues
 Um produto a ser entregue Um produto a ser entregue éé o resultado do o resultado do 
projeto entregue