Escolar Documentos
Profissional Documentos
Cultura Documentos
Engenharia de Software
AUTORIA
Ricardo Bortolo Vieira
Bem vindo(a)!
Meu objetivo principal com este livro é apresentar os conceitos mais importantes da
engenharia de software e discutir técnicas para gerenciar o processo de
desenvolvimento de software. Este processo vai auxiliar você a levantar as
necessidade de cada empresa e produto e analisar cada necessidade apresentada e
escolher o melhor processo. Além disso, pretendo deixar claro que o uso correto dos
conceitos de engenharia de software podem ajudá-lo a alcançar os objetivos
estratégicos de sua empresa ou auxiliá-lo a colocar em prática uma nova ideia.
AUTORIA
Ricardo Bortolo Vieira
Introdução
Caro(a) aluno(a), neste capítulo, trataremos de assuntos iniciais importantes paro o
bom entendimento dos demais capítulos desta apostila. Para tanto, conceitos
genéricos serão explicados (como software, dados, informações, engenharia de
software), fornecendo uma visão geral, do funcionamento do processo até chegar a
de nição de engenharia de software propriamente dito e as atividades que são
essenciais para esse processo, desde a engenharia de requisitos até os testes e
evolução do software.
Além disso, será apresentado a Linguagem de Modelagem Uni cada (UML) que
representa uma linguagem visual extremamente poderosa e não ambígua. Esta
linguagem é muito importante para o engenheiro de software pois assim ele pode
desenhar o processo de software baseado nas regras de negócio, independente da
linguagem de desenvolvimento. Ainda neste tópico conheceremos alguns exemplos
de software CASE baseadas em UML para apoiar o processo da engenharia de
software e torná-la mais e ciente e reutilizável.
Bons estudos!
Introdução a Engenharia
de Software
AUTORIA
Ricardo Bortolo Vieira
A maior parte dos serviços e infraestruturas são controladas atualmente por
software (SOMMERVILLE, 2011). Ele é importante porque afeta quase todos os
aspectos da nossa vida e está incorporado no comércio, na cultura e nas atividades
cotidianas (PRESSMAN, 2011). Por isso o mundo moderno não poderia existir sem o
software (SOMMERVILLE, 2011).
AUTORIA
Ricardo Bortolo Vieira
"Software de computador é o produto que pro ssionais de software desenvolvem e
ao qual dão suporte no longo prazo. Abrange programas executáveis em um
computador de qualquer porte ou arquitetura, conteúdos (apresentados à medida
que os programas são executados), informações descritivas tanto na forma impressa
como na virtual, abrangendo praticamente qualquer mídia eletrônica." (PRESSMAN,
2011, p.29)
Segundo Pressman (2011), software é mais um elemento lógico do que físico. Desta
maneira há algumas características que o diferencia de hardware:
Todo projeto de software se inicia por alguma necessidade de negócios, seja ela de
corrigir algum defeito de uma aplicação já existente, a necessidade de estender as
funções e ou recursos ou a de criar um novo produto, serviço ou sistema
(PRESSMAN, 2011).
AUTORIA
Ricardo Bortolo Vieira
Fazer software não é uma tarefa fácil, software de qualidade é ainda mais difícil.
Todavia, mesmo apresentando baixa qualidade, o interesse das organizações pelo
desenvolvimento de sistemas tem aumentado. Isso porque as organizações
reconhecem que software é fonte de importantes vantagens competitivas (SILVA;
VIDEIRA, 2001).
1. Cada vez mais os indivíduos dependem de software avançado. Por isso eles
devem ser produzidos de forma con ável, econômica e rápida;
2. Em longo prazo, é mais barato usar métodos e técnicas de engenharia de
software para sistema de software.
Uma das primeiras de nições da Engenharia de Software foi dada por Fritz Bauer no
nal dos anos 60: “a de nição e utilização de princípios de engenharia sólidos, de
modo a desenvolver software econômico, con ável e que trabalha e cientemente
em máquinas reais. Inclui um conjunto de métodos, de ferramentas e de
procedimentos” (BAUER, 1971, p. 524).
Outra de nição, mais comumente usado foi proposta por Potts na IEEE em 1993: "a
Engenharia de Software é a aplicação de um processo sistemático, disciplinado e
quanti cado ao desenvolvimento, operação e manutenção de software, ou seja, e
Engenharia de Software é a aplicação de técnicas da Engenharia de Software"
(POTTS, 1993, p. 20).
Ferramentas
Métodos
Processo
Foco na qualidade
AUTORIA
Ricardo Bortolo Vieira
Um software não pode ser desenvolvido de qualquer jeito, sem seguir critérios, sem
que se saiba qual o próximo passo a ser dado. Por isso que os conceitos relacionados
à engenharia de software devem ser utilizados. Hoje em dia, a empresa precisa
de nir qual o seu processo de software.
Uma ação pode ser de nida como um conjunto de tarefas que resultam num
artefato de software fundamental (PRESSMAN, 2011).
Para Sommerville (2011), existem muitos processos de software diferentes, mas todos
eles incluem pelo menos quatro atividades fundamentais para a Engenharia de
Software.
Mas o que acontece é que nem sempre as empresas aproveitam as boas técnicas da
engenharia de software em seu desenvolvimento de software. E, normalmente, o
software não atende aos requisitos do usuário, acaba demorando mais tempo para
ser desenvolvido do que o previsto, aumentando assim, o valor do custo do software.
Princípios que orientam a
prática dos modelos de
processo de software
AUTORIA
Ricardo Bortolo Vieira
Todos os modelos de processos de software podem acomodar as atividades
essenciais descritas no tópico anterior, porém cada um deles dá uma ênfase
diferente a essas atividades e de ne um uxo de processo que invoca essas
atividades de diferentes formas (PRESSMAN, 2011).
Solicitação de mudança
de requisitos
Desenvolvimento ágil
Engenharia Projeto e
de requisitos implementação
AUTORIA
Ricardo Bortolo Vieira
Modelo Cascata
Modelo de processo prescritivo, proposto para trazer ordem ao caos existente no
desenvolvimento de software, fornecendo um roteiro razoavelmente e caz para as
equipes de desenvolvimento de software. O modelo cascata sugere uma
abordagem seqüencial e sistemática, começando com levantamento de requisitos
com o cliente e passando pelas fases de planejamento, modelagem, construção e
entrega. É normalmente utilizado quando os requisitos são bem compreendidos ou
quando adaptações ou aperfeiçoamento são bem de nidos (PRESSMAN, 2011).
Requerimento
Projeto
Especificação
de requisitos
Especificação
de requisitos
Especificação
de requisitos
Modelo Incremental
Também é um modelo prescritivo, em que os requisitos iniciais são razoavelmente
bem de nidos, no entanto, um processo puramente linear não é usado. O
fornecimento de partes do sistema ao usuário é necessário para que se possa re nar
e expandir suas funcionalidades em versões posteriores (PRESSMAN, 2011).
Incremento n
Comunicação
Planejamento
Modelagem
Incremento 2
Construção
Comunicação
Funcionalidades e características do projeto
Implantação
Planejamento
Entrega n
Modelagem
Incremento 1
Construção
Comunicação
Implantação
Planejamento
Entrega 2
Modelagem
Construção
Implantação
Entrega 1
núcleo do produto
Tempo do projeto
Modelo Espiral
O software é desenvolvido de maneira que possa evoluir ao longo do tempo. Acopla
iteratividade e prototipação com os aspectos sistemáticos e controlados do modelo
cascata (PRESSMAN, 2011).
Figura 5 - Modelo Espiral.
Determinar Identificar e
objetivos resolver riscos
Existe também o chamado processo uni cado, que é uma metodologia para
engenharia de software orientada a objetos usando a UML e reúne as melhores
práticas dos modelos já existentes (PRESSMAN, 2011).
Modelos de
desenvolvimento ágil
AUTORIA
Ricardo Bortolo Vieira
Em 2001, Kent Beck e outros dezesseis renomados desenvolvedores, autores e
consultores da área de software assinaram o "Manifesto para o Desenvolvimento Ágil
de Software”. Normalmente, um manifesto é associado a um movimento político
emergente: atacando a velha guarda e sugerindo uma mudança revolucionária. De
certa forma, é exatamente do que trata o desenvolvimento ágil (PRESSMAN, 2011).
Por que Scrum? Criei o Scrum, junto com Ken Schwaber, há vinte anos,
como um jeito mais rápido, con ável e e ciente de desenvolver
softwares na indústria de tecnologia. Até aquele momento — e até
2005 —, a maior parte do desenvolvimento de softwares era executada
com base no método em cascata, de acordo com o qual um projeto era
concluído em etapas distintas e levado passo a passo até o lançamento
para Os consumidores ou usuários. O processo era lento, imprevisível, e
muitas vezes não resultava em um produto que as pessoas quisessem
ou pelo qual se dispusessem a pagar. Atrasos de meses, ou até mesmo
anos, eram endêmicos. Os antigos planos passo a passo,
confortavelmente detalhados em diagramas de Gantt, davam à
gerência uma sensação de que se tinha total controle sobre o
desenvolvimento de um projeto. No entanto, na maioria esmagadora
dos casos, em pouco tempo os atrasos em relação ao cronograma
começavam e o orçamento era ultrapassado em uma escala
desastrosa.
Planning/Feedback Loops
Release Plan
Months
Interation plan
Weeks
Acceptance Test
Days
Stand Up Meeting
One day
Pair Negotiation
Hours
Unit Test
Minutes
Pair programming
Seconds
Code
SCRUM
Reunião diária
Quadros Objetivos
de tarefas da sprint
Incremento
feedback Potencialmente
Estragável
Sprint
( 1 - 4 semanas)
Retrospectiva
Time Scrum
Ações de
melhoria
Product Scrum Time de
Owner Master Desenvolvimento
Planejamento da Sprint
Product Backlog Objetivo da Sprint
Sprint Backlog
Product
Refinamento Backlog
AUTORIA
Ricardo Bortolo Vieira
A UML (Uni ed Modeling Language ou Linguagem de Modelagem Uni cada) é
uma linguagem grá ca, utilizada para a elaboração da estrutura de projetos de
software. Constrói modelos concisos, precisos, completos e sem ambiguidades,
tendo, de maneira geral, as seguintes características, segundo Pereira (2011):
Esta linguagem utiliza diversos símbolos grá cos, e possui uma semântica bem
de nida para cada um deles, sendo possível elaborar diversos modelos. A UML tem
sido empregada de maneira efetiva em sistemas cujos domínios abrangem:
sistemas de informações corporativos, serviços bancários e nanceiros, transportes,
serviços distribuídos baseados na Web entre outros. Porém, a UML, não se limita à
modelagem de software, podendo modelar sistemas como o uxo de trabalho no
sistema legal, a estrutura e o comportamento de sistemas de saúde e o projeto de
hardware.
Ela surgiu da junção de 3 grandes métodos: Método Booch de Grady Boock, Método
OMT (Object Modeling Technique) de Rumbaugh e do método OOSE (Object-
Oriented Software Engineering) de Jacobson. Esses eram, até meados da década de
1990, as três metodologias de modelagem orientada a objetos mais populares entre
os engenheiros de software (GUEDES, 2011).
A UML é baseada no paradigma de orientação a objetos (OO), que está ligado a nove
conceitos (JONES, 2001):
1. Encapsulamento;
2. Ocultação de informação e Implementações;
3. Retenção de Estado;
4. Identidade de Objeto;
5. Mensagens;
6. Classes;
7. Herança;
8. Polimor smo; e
9. Generalização.
Em sua última versão vigente, 2.5, a UML possui 14 diagramas vigentes apresentados
na Figura 8.
Figura 8 - Organograma da UML 2.5.
Diagrama
Diagrama de Diagrama de
estruturas comportamentos
AUTORIA
Ricardo Bortolo Vieira
Uma ferramenta CASE (Computer-Aided Software Engineering - Engenharia
de Software Auxiliada por Computador) é um software que, de alguma forma,
colabora na realização de uma ou mais atividades da engenharia de software.
Rational Rose é uma ferramenta CASE, mais especi camente, uma ferramenta UML
que auxilia nos processos de construção de um software pro ssional. Hoje em dia
essa ferramenta tem um peso no mercado sendo usada por diversos pro ssionais e
grandes empresas. Foi criada pela Rational que, posteriormente foi adquirida pela
IBM em 20 de fevereiro de 2003 e a ferramenta não é gratuita. Permite a
modelagem com os quatorze diagramas da UML. Permite também a construção de
modelos de Dados com possibilidade de exportação para construção da base de
dados ou realização de engenharia reversa de uma base de dados existente. Dá
suporte ao Visual Studio (pacote de programas para desenvolvimento de software
da Microsoft). Foi sucedido pelo IBM Rational Architect.
Figura 10 - Logotipo do Software Rational Rose
Visual Paradigm for UML é uma ferramenta CASE com várias opções de
modelagem com os diagramas da UML 2.0 e que também oferece suporte a
diagramas de requisitos SysML e a diagramas ER (Entidade Relacionamento). A
ferramenta possui um bom ambiente de trabalho, o que facilita a visualização e
manipulação do projeto de modelagem. É uma ferramenta comercial e também
oferece suporte a transformações especí cas para códigos-fonte de algumas
linguagens de programação como, por exemplo, C++ e Java.
Figura 12 - Logotipo do Software Visual Paradigm
Esta é uma das várias situações relatadas pelo autor Peter Mellor em
seu artigo "computer-aided disaster" publicado em 1994. Peter é
professor na University of Northampton, em Londres. Este e muitos
outros relatos de tragédias com falhas de software nos mostram como
é importante investir tempo e dinheiro em engenharia de software para
minimizar estes impactos que as falhas de software trazem para as
operações das empresas e para nossas vidas.
REFLITA
“As pessoas apostam seus empregos, seu conforto, sua segurança, sua
diversão, suas decisões e suas próprias vidas nos softwares de
computadores. Eles precisam estar certos”.
Até lá!
Leitura complementar
ACESSAR
Livro
Filme
Acesse o link
Referências
ASTAH (2006). Astah Community - Free UML Modeling tool I Astah.net.
http://astah.net/editions/community, <acessado em 18/07/2019>
SPARK Systems Pty Ltd. (2000). Enterprise Architect Downloads I Sparx Systems.
https://spa rxsystems.com/prod ucts/ea/down loads.htm 1<acessado em 18/07/2019>
SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade do
tempo. Leya, 2016.
VISUAL-PARADIGM (2002). Ideal Modeling & Diagramming Tool for Agile Team
Collaboration. https://www.visual-paradigm.com/ <acessado em 18/07/2019>
AUTORIA
Ricardo Bortolo Vieira
Introdução
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de projeto
de software, proporcionando as seguintes discussões:
Além disso, será apresentado a importância de cada um destes projetos, bem como
os processos e artefatos necessários para o desenvolvimento destes projetos.
AUTORIA
Ricardo Bortolo Vieira
Introdução (H1)
É um processo criativo no qual de ne-se uma organização de um sistema para
satisfazer aos requisitos funcionais e não funcionais. Aspectos que in uenciam a
arquitetura:
Para exempli car a arquitetura que estou descrevendo aqui apresento a Figura 13
que mostra a arquitetura de repositório de uma determinada IDE (Integrated
Development Environment - Ambiente de Desenvolvimento Integrado) . Este tipo
de arquitetura é usada para sistemas com grandes volumes de dados a serem
armazenados ou em sistemas baseados em informação, pois quando algo é
adicionado ou removido do repositório uma ação ou tarefa pode ser realizada.
Editores Geradores
UML de código
Editores
java
Tradutor
de projeto Repositório do projeto
Editor
Python
Analisador Gerador
de projeto de relatório
Diagramas de bloco são uma forma adequada de, durante o processo de projeto,
descrever a arquitetura do sistema. Estes diagramas representam uma boa maneira
de apoiar a comunicação entre as pessoas envolvidas no processo. Em muitos
projetos, eles são a única documentação de arquitetura que existe. No entanto, se a
arquitetura de um sistema deve ser bem documentada, é melhor usar uma notação
com semântica bem de nida para a descrição de arquitetura.
Visão da arquitetura
Os modelos de arquitetura de um sistema de software podem ser usados para focar
a discussão sobre os requisitos de software ou de projeto. Além disso, podem ser
usados para documentar um projeto para que este possa ser usado como base para
um projeto e uma implementação mais detalhados e para a futura evolução do
sistema.
Padrões de arquitetura
Um padrão de arquitetura é uma descrição genérica de uma organização do
sistema:
MVC
Tabela 1 - O padrão modelo-visão-controle (MVC).
Nome Característica
Repositório
Tabela 2 - O padrão Repositório.
Nome Característica
Cliente-Servidor
Tabela 3 - O padrão Cliente-Servidor.
Nome Característica
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste tópico, irei descrever uma abordagem sobre o reúso de
software baseado na composição de componentes reusáveis, padronizados. E
segundo Sommerville (2011), muitos novos sistemas de negócios são desenvolvidos
pela con guração de sistemas disponíveis no mercado. No entanto, quando uma
empresa não pode usar um "sistema de prateleira", porque eles não atendem a seus
requisitos, o software de que necessitam precisa ser especialmente desenvolvido.
Para o desenvolvimento de software customizado, a engenharia de software
baseada em componentes é uma forma e caz, orientada ao reúso, de desenvolver
novos sistemas corporativos.
Modelo de Componentes
Para Sommerville (2011), a Tabela 4 mostra o que deve ser considerado como
característica para um componentes seguindo os preceitos da CBSE.
Tabela 4 - Característica de um componente.
Característica
do Descrição
componente
Convenção
Composição Customização Documentação
de nomes
Informações Implantação
Interfaces
de uso e uso
Modelos de componentes
Processos CBSE
Na Figura 16, você pode ver que os processos básicos CBSE com e para reúso apoiam
os processos que estão preocupados com a aquisição de componente,
gerenciamento de componente e certi cação de componente.
Figura 16 - Processos CBSE.
PROCESSOS CBSE
Especificador,
CBSE CBSE projetista,
para reúso com reúso Integrador,
Mantenedor
Analista de domínio,
Projetista,
Implementador, Bibliotecário,
Aquisição de
Mantenedor, Vendedor,
componentes
Analista de mercado. Agente
Fonte externa
Certificação
myri Bibliotecário
de componentes
Certificador
local ou externo
Repositório
de componentes
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste capítulo, iremos discutir sobre a Interface com o Usuário e a
importância dela para os softwares e aplicativos da atualidade.
Visando tornar a interação com o usuário mais natural e menos hostil, às interfaces
passaram a ser constituídas, entre outros itens, por elementos grá cos, onde
imagens representando dados e tarefas disponíveis são manipuladas diretamente
pelo usuário. Na realidade, tais itens não constituem os dados nem as tarefas; são
apenas seus signos, isto é tudo que possa ser assumido como um substituto
signi cante de outra coisa qualquer.
Segundo Mandel (1997) as três regras de ouro dos projetos de interface de usuário
são:
Usuário no Comando
A maioria das restrições de interface impostas por um designer tem a intenção de
simpli car o modo de interação. Mas para quem?
Como designer, você pode se sentir tentado a introduzir restrições e limitações para
simpli car a implementação da interface. O resultado pode ser uma interface fácil
de construir, mas frustrante de usar. Mandel (1997) de ne vários princípios de design
que permitem ao usuário manter este controle tão desejado:
De na os modos de interação de uma maneira que não force o usuário a ações
desnecessárias ou indesejadas;
Providencie interação exível. Como usuários diferentes têm diferentes
preferências de interação, as opções devem ser fornecidas;
Permitir que a interação do usuário seja interrompível e que possa ser desfeita;
Agilize a interação à medida que os níveis de habilidade avançam e permitem
que a interação seja personalizada;
Ocultar internos técnicos do usuário casual. A interface do usuário deve mover
o usuário para o mundo virtual do aplicativo;
Design para interação direta com objetos que aparecem na tela.
AUTORIA
Ricardo Bortolo Vieira
Caro(a) aluno(a), neste capítulo, trataremos de padrões de projeto. Este assunto
trata sobre soluções gerais para um problema que ocorre com frequência dentro do
contexto de projetos de software.
Segundo Pressman (2011), O projeto baseado em padrões cria uma nova aplicação
através da busca de um conjunto de soluções comprovadas para um conjunto de
problemas claramente delineados. Cada problema é descrito por um padrão de
projeto que foi catalogado e investigado por outros engenheiros de software que
depararam com o problema e implementaram a solução ao projetarem outras
aplicações. Cada padrão de projeto nos oferece uma abordagem comprovada para
parte do problema a ser resolvido.
Modelo de
requisitos
O projeto é iniciado
Considerar
Considerar Extrair contexto
atributos
conceitos das forças e
de qualidade
de projeto do problema
do projeto
Tratado pelo
padrão?
Sim Não
Modelo de
projeto
Antes que qualquer um dos padrões de arquitetura citados anteriormente possa ser
escolhido, ele deve ser avaliado em termos de sua adequação para a aplicação e
estilo de arquitetura geral, bem como o contexto e o sistema de forças que ele
especi ca.
Tendo enunciado o subproblema que deve ser resolvido, devemos considerar agora
o contexto e o sistema de forças que afetam uma solução. Assim, podemos perceber
que a solução para o subproblema envolve uma pesquisa. Como pesquisar é um
problema muito comum, não deve ser nenhuma surpresa a existência de muitos
padrões relacionados à pesquisa. Pressman (2011) apresenta alguns destes padrões:
É atribuído um
identi cador exclusivo a
cada página ou tela. O
Fornece um caminho
caminho de navegação
de navegação
para O local atual é
completo quando o
especi cado em um local
usuário está
BreadCrumbs prede nido para qualquer
trabalhando com
tela. O caminho assume a
uma hierarquia de
forma: homepage>página
páginas ou telas
de tópico
complexa.
principal>página de
subtópico>página
especí ca>página atual.
Oferece a capacidade de
pesquisar local ou
Oferece a capacidade
globalmente no site. Gera
de pesquisar em um
uma lista de “acertos” em
site ou fonte de
ordem de probabilidade
dados persistentes
SimpleScarch para atender às
para um dado
necessidades do usuário.
simples descrito em
Não oferece buscas de
uma string
itens múltiplos ou
alfanumérica.
operações booleanas
especiais.
Uma discussão completa para interfaces do usuário vai além do escopo deste livro,
assim, recomendo os seguintes livros para mais informações: Borchers (2001) e
Duyne (2002).
SAIBA MAIS
Um bom software, segundo Sommerville (2011), tem quatro atributos
essenciais:
REFLITA
“Toda vez que pensar ‘não temos tempo para a engenharia de software’,
pergunte para si mesmo, ‘teremos tempo para fazer de novo?’”
Livro
Filme
Acesse o link
Unidade 3
Qualidade e Técnicas de
Revisão
AUTORIA
Ricardo Bortolo Vieira
Introdução
Olá Caro(a) aluno(a)! Neste capítulo meu objetivo é introduzir os conceitos de
qualidade de software, tratando sobre:
AUTORIA
Ricardo Bortolo Vieira
No desenvolvimento de software, a qualidade de um projeto engloba o grau de
atendimento às funções e características especi cadas no modelo de requisitos. A
qualidade de conformidade focaliza o grau em que a implementação segue o
projeto e o sistema resultante atende suas necessidades e as metas de
desempenho. Mas estas são as únicas questões que o engenheiro de software deve
considerar? (PRESSMAN, 2011)
Dessa forma, Sommerville (2011) discute que existe uma clara ligação entre a
qualidade de processo e de produto na manufatura porque o processo é
relativamente fácil de ser padronizado e monitorado. Uma vez que sistemas de
manufatura sejam calibrados, eles podem ser executados várias vezes para produzir
produtos de alta qualidade. No entanto, o software não é manufaturado, ele é criado.
No desenvolvimento de software a relação entre a qualidade de processo e de
produto é mais complexa e por isso a padronização do processo é importante para
auxiliar nesta tarefa.
Padrões de Software
Os padrões de software desempenham um papel muito importante no
gerenciamento da qualidade de software. Como já discutido, uma parte importante
da garantia de qualidade é a de nição ou seleção de padrões que devem ser
aplicados no processo de desenvolvimento de software ou produtos de software.
Como parte desse processo, devem ser escolhidas ferramentas e métodos para
suportar o uso desses padrões. Os padrões de software são importantes por três
razões, conforme descrito por Sommerville (2011):
Existem dois tipos de padrões de engenharia de software que podem ser de nidos e
usados no gerenciamento de qualidade de software:
AUTORIA
Ricardo Bortolo Vieira
Conforme Pressman (2011), à medida que desenvolvemos o trabalho de engenharia
de software, cometemos erros, isso é aceitável, desde que sejamos capazes de criar
processos para detectar isso antes do usuário nal. Assim, as revisões técnicas são o
mecanismo mais efetivo para encontrar estes erros. Dessa forma, os engenheiros de
software realizam as revisões técnicas, também chamadas revisões paritárias,
juntamente com seus colegas.
Revisões Informais
Como exemplos de revisões informais, Pressman (2011) cita:
Quaisquer erros ou problemas veri cados pelos revisores são registrados pelo
projetista para resolução futura. Poderiam ser programados testes de mesa de
forma ad hoc ou eles seriam compulsórios, como parte da boa prática de
engenharia de software. Em geral, a quantidade de material a ser revisada é
relativamente pequena e o tempo total gasto em um teste de mesa vai um pouco
além de uma ou duas horas.
Revisões Formais
Conforme Pressman (2011), Revisão Técnica Formal (RTF) é uma atividade de
controle da qualidade de software realizada por engenheiros de software e outros
pro ssionais. Os objetivos de uma RTF são:
Assim, uma RTF se concentra em uma parte especí ca (e pequena) do software. Por
exemplo, em vez de tentar revisar um projeto inteiro, os passos detalhados são
realizados para cada componente ou para um pequeno grupo de componentes.
Para ser e caz, o processo de revisão por amostragem deve tentar quanti car
aqueles produtos de trabalho que são alvos primários para as RTFs completas, Para
conseguir isso, são sugeridas as seguintes etapas:
AUTORIA
Ricardo Bortolo Vieira
"A principal responsabilidade de uma pessoa do Software Quality Assurance (SQA) é
examinar e medir o processo de desenvolvimento de software atual e encontrar
maneiras de melhorá-lo com o objetivo de evitar que os erros ocorram." (PATTON,
2006, p. 520)
Além de cada uma dessas preocupações e atividades, a SQA trabalha para garantir
que atividades de suporte ao software sejam realizadas ou produzidas tendo a
qualidade como preocupação dominante. A prerrogativa do grupo de SQA é ajudar
a equipe de software a obter um produto nal de alta qualidade. Essas ações,
apresentadas por Pressman(2011), são realizadas (ou facilitadas) por um grupo de
SQA que:
Qualidade do projeto. Todo elemento do modelo de projeto deve ser avaliado pela
equipe de software para garantir que apresente alta qualidade e que o próprio
projeto esteja de acordo com os requisitos. A SQA busca atributos do projeto que
sejam indicadores de qualidade.
O que torna o CMMI especial é que ele é genérico e se aplica igualmente a empresas
de software de qualquer tamanho, desde a maior empresa de software do mundo
até uma consultoria de uma única pessoa. Seus cinco níveis, apresentados na Figura
9, fornecem um meio simples para avaliar a maturidade de desenvolvimento de
software de uma empresa e determinar as principais práticas que podem adotar
para passar para o próximo nível de maturidade.
Foco continuo na
5 Otimização
melhoria dos processos
Ao estudar a Figura 19, extraída do site ISD BRASIL (Integrated System Diagnostic
Brasil), pense no seguinte: Se você tomar todo o universo das empresas de software
hoje, a maioria está no Nível de Maturidade 1, muitos estão no Nível de Maturidade 2
e menos no Nível de Maturidade 3, um punhado está no nível de maturidade 4, e
uma elite de poucos estão no nível de maturidade 5.
ISO 9000
Ainda buscando inspiração em Patton (2006), apresento outro conjunto popular de
padrões relacionados à qualidade de software que é a International Organization for
Standardization (ISO) 9000. A ISO é uma organização internacional que de ne
padrões para tudo, desde porcas e parafusos até, no caso da ISO 9000,
gerenciamento de qualidade e garantia de qualidade.
Você pode ter ouvido falar da ISO 9000 ou notado em propagandas de produtos ou
serviços de uma empresa. Geralmente é um pequeno logotipo ou nota ao lado do
nome da empresa. É um grande negócio ter a certi cação ISO 9000 e uma empresa
que a tenha alcançado quer tornar esse fato conhecido de seus clientes,
especialmente se seus concorrentes não são certi cados.
A ISO 9000 funciona bem pois tem como alvo o processo de desenvolvimento, não o
produto. Preocupa-se com a maneira como uma organização realiza seu trabalho,
não com os resultados do trabalho. Ele não tenta de nir os níveis de qualidade dos
aplicativos que saem da linha de montagem ou do software no CD (Compact Disk).
Como você aprendeu, a qualidade é relativa e subjetiva. O objetivo de uma empresa
deve ser criar o nível de qualidade que seus clientes desejam. Ter um processo de
desenvolvimento de qualidade ajudará a conseguir isso.
A ISO 9000 determina apenas quais são os requisitos do processo e não como eles
devem ser alcançados. Realizar revisões de projeto é um bom exercício que uma
equipe de projeto responsável deve fazer (e é por isso que está na ISO 9000), mas
exatamente como a revisão de projeto deve ser organizada e executada depende da
equipe individual que cria o produto. A ISO 9000 diz o que fazer, mas não como fazê-
lo.
AUTORIA
Ricardo Bortolo Vieira
Conforme Pressman (2011) estabelece muito bem, estratégia de teste de software
fornece um roteiro que descreve os passos a serem executados como parte do teste,
de ne quando esses passos são planejados e então executados, e quanto trabalho,
tempo e recursos serão necessários. Portanto, qualquer estratégia de teste deve
incorporar planejamento dos testes, projeto de casos de teste, execução dos testes,
coleta e avaliação dos dados resultantes.
Uma estratégia de teste de software deve ser exível o bastante para promover uma
abordagem de teste personalizada. Ao mesmo tempo, deve ser rígida o bastante
para estimular um planejamento razoável e o acompanhamento, à medida que o
projeto progride.
Test-Case Design
Os testes, conforme Myers (2004), por mais criativos e aparentemente completos,
não podem garantir a ausência de todos os erros. O design de casos de teste é tão
importante porque testes completos são impossíveis. Em outras palavras, um teste
de qualquer programa deve ser necessariamente incompleto. A estratégia óbvia,
então, é tentar fazer testes tão completos quanto possível. Dadas as restrições de
tempo e custo, a questão-chave do teste torna-se: Qual subconjunto de todos os
possíveis casos de teste tem a maior probabilidade de detectar a maioria dos erros?
A primeira é que um teste de caminho exaustivo não garante de modo algum que
um programa corresponda à sua especi cação. Por exemplo, se você fosse solicitado
a escrever uma rotina de classi cação de ordem crescente, mas produzisse
erroneamente uma rotina de classi cação de ordem decrescente, o teste de
caminho exaustivo seria de pouco valor; o programa ainda tem um bug: é o
programa errado, pois não atende a especi cação.
Terceiro, um teste de caminho exaustivo pode não revelar erros de sensibilidade aos
dados. Suponha que em um programa você tenha que comparar dois números para
convergência, isto é, para ver se a diferença entre os dois números é menor do que
algum valor predeterminado. Naturalmente, a instrução contém um erro porque
deve comparar c ao valor absoluto de a-b. A detecção desse erro, no entanto,
depende dos valores usados para a e b e não seria necessariamente detectada
apenas pela execução de todos os caminhos do programa.
Nesta abordagem, os dados de teste são derivados apenas das especi cações (ou
seja, sem tirar proveito do conhecimento da estrutura interna do programa).
Se você quiser usar essa abordagem para encontrar todos os erros no programa, o
critério é um teste de entrada exaustivo, fazendo uso de todas as condições de
entrada possíveis como um caso de teste. Por quê? Se você tentou três casos de
teste de triângulo equilátero para o programa de triângulo, isso não garante de
forma alguma a detecção correta de todos os triângulos equiláteros. Como o
programa é uma caixa preta, a única maneira de ter certeza de detectar a presença
de tal declaração é tentar todas as condições de entrada.
Para testar exaustivamente o programa do triângulo, você teria que criar casos de
teste para todos os triângulos válidos até o tamanho inteiro máximo da linguagem
de desenvolvimento. Isso em si é um número astronômico de casos de teste, mas
não é de forma alguma exaustivo. Para ter certeza de encontrar todos esses erros,
você deve testar usando não apenas todas as entradas válidas, mas todas as
entradas possíveis. Assim, para testar exaustivamente o programa do triângulo, você
teria que produzir virtualmente um número in nito de casos de teste, o que, é claro,
não é possível.
1. Você não pode testar um programa para garantir que esteja livre de erros;
2. Uma consideração fundamental no teste de programas é uma questão de
economia.
Como os testes exaustivos estão fora de questão, o objetivo deve ser maximizar o
rendimento do investimento em testes maximizando o número de erros
encontrados por um número nito de casos de teste. Fazer isso envolverá, entre
outras coisas, ser capaz de procurar dentro do programa e fazer certas suposições
razoáveis sobre o programa.
SAIBA MAIS
Para apoiar os pro ssionais da qualidade na gestão de seus processos e
problemas diários foram criados associações e organizações que criam,
discutem e organizam padrões e fontes de informação gerais e
especí cas para a gestão de todo o processo da qualidade. Veja aqui os
sites que são um bom ponto de partida para ter acesso a essas
associações:
ACESSAR
ACESSAR
ACESSAR
ACESSAR
ACESSAR
ACESSAR
REFLITA
"As pessoas esquecem quão rápido um trabalho foi realizado - mas elas
sempre lembram quão bem ele foi realizado"
A Técnica de Revisão é o processo pela qual buscamos rever o que foi desenvolvido
em busca de erros para serem corrigidos, pois cometemos erros, isso é aceitável,
desde que sejamos capazes de criar processos para detectar isso antes do usuário
nal. Assim, as revisões técnicas são divididas em duas partes: as revisões formais e as
revisões informais. As formais possuem um grande formalismo e envolve um
processo descrito no tópico, já as revisões informais são muito pontuais e utilizadas
pelos desenvolvedores para casos especí cos do dia a dia do desenvolvimento. Além
disso discutimos também a necessidade da revisão baseada em amostragem, pois na
vida real temos milhões de linhas de código desenvolvidas para cada sistema de
criamos.
É isso ai pessoal, mais uma Unidade termina, com muito conhecimento e propostas
de estudos futuros pois a área de qualidade possui muito conteúdo além do que
vimos até aqui e oferece uma carreira muito proeminente. Espero que aqueles que se
interessaram pela área busquem mais conhecimento e oportunidades como
pro ssionais da qualidade. Na próxima Unidade falaremos sobre outra grande área
de conhecimento, que é a área de Gerenciamento de Projetos.
Livro
Filme
Acesse o link
Referências
ISO BRASIL, O que é CMMI: CONSULTORIA EM CMMI, QUALIDADE, COVERNANÇA,
E-LEARNINC, CERTIFICAÇÕES ([S.d.]). http://www.isdbrasil.eom.br/o-que-e-cmmi.php,
<acessado em 03/07/2018>.
MYERS, Glenford J. et ai. The art of software testing. Chichester: John Wiley & Sons,
2004.
AUTORIA
Ricardo Bortolo Vieira
Introdução
Nesta Unidade você aprenderá as técnicas de gerenciamento necessárias para
planejar, organizar, monitorar e controlar projetos de software. Estes estudam visam
resolver as seguintes questões:
Uma vez respondidas essas questões, estaremos mais preparados para os desa os
do dia a dia da gestão de projetos, mais especi camente a gestão de projetos de
software.
AUTORIA
Ricardo Bortolo Vieira
O conhecimento sobre projetos, acumulado até o presente momento (pela nossa
civilização moderna), permite notar que, por mais diferentes que sejam o propósito e
a dimensão dos projetos em diferentes organizações, eles são baseados nos mesmo
conceitos comuns (SABBAG, 2013). Vamos discutir alguns deles:
Singularidade
Percebe-se que projeto tem algo de inusitado ou desconhecido, diríamos único, e
por isso se torna tão desa ador.
Temporariedade
A expectativa do prazo norteia estes projetos. Ora, se há este tipo de meta, logo os
projetos são temporários. E caso sejam temporários, possuem um ciclo de vida a
considerar. Projetos são concebidos, evoluem até sua maturidade, apresentam
declínio e, são concluídos. A data de término é crucial para todo o projeto e como
isto se torna um problema para as organizações.
Gerenciamento de Projetos
Podemos descrevê-lo como a aplicação de conhecimento, habilidades, ferramentas
e técnicas às atividades do projeto buscando atender às suas demandas, sendo
realizado por meio da integração dos seguintes processos: iniciação, planejamento,
execução, encerramento e monitoramento e controle. Conforme o PMBOK (Project
Management Body Of Knowledge) do PMI (Project Management Institute) (2017).
Tim
e
op
e
Sc
QUALITY
Cost
Fonte: BEWARE (2000)
AUTORIA
Ricardo Bortolo Vieira
Métricas de processo são coletadas através de todos os projetos e sobre longos
períodos de tempo. Sua nalidade é proporcionar uma série de indicadores de
processo que levam à melhoria do processo de software no longo prazo. Métricas de
projeto permitem ao gerente de projeto de software (1) avaliar o estado de um
projeto em andamento, (2) rastrear os riscos em potencial, (3) descobrir áreas
problemáticas antes que elas se tornem críticas, (4) ajustar o uxo de trabalho ou
tarefas, e (5) avaliar a habilidade da equipe de projeto para controlar a qualidade dos
produtos nais de software. Estas de nições são estabelecidas por Pressman (2011).
O objetivo das métricas de projeto é duplo. Primeiro, essas métricas são usadas para
minimizar o cronograma de desenvolvimento fazendo os ajustes necessários para
evitar atrasos e mitigar problemas e riscos em potencial. Segundo, as métricas de
projeto são usadas para avaliar a qualidade do produto de forma contínua e, quando
necessário, modi car a abordagem técnica para melhorar a qualidade.
Métricas orientadas por tamanho não são aceitas universalmente como a melhor
maneira de medir os processos de software. A maior parte da controvérsia gira em
torno do uso de linhas de código como medida principal. Os defensores da medida
LOC (linhas de código) argumentam que LOC é um “item” de todos os projetos de
desenvolvimento de software que pode ser facilmente contado. Por outro lado, os
oponentes argumentam que as medidas LOC são dependentes da linguagem de
programação, que quando é considerada a produtividade, elas penalizam
programas bem projetados, mas menores; que elas não podem facilmente
acomodar linguagens não procedurais; e que seu uso nas estimativas requerem um
nível de detalhe que pode ser difícil de alcançar.
Métricas orientadas a função
Métricas de software orientadas a função, conforme Vazquez (2013), usam uma
medida da funcionalidade fornecida pela aplicação como um valor de normalização.
A métrica orientada a função mais amplamente usada é a pontos de função
(function point — FP). O cálculo de pontos de função é baseada nas características
de domínio de informação e complexidade do software.
A métrica ponto de função pode ser usada efetivamente como um meio para medir
a funcionalidade fornecida por um sistema. Por meio de dados históricos, a métrica
FP pode ser empregada para (1) estimar o custo ou trabalho necessário para
projetar, codi car e testar o software; (2) prever o número de erros que serão
encontrados durante o teste; e (3) prever o número de componentes e/ou o número
de linhas projetadas de código-fonte no sistema implementado.
Pontos de função são derivados por meio de uma relação empírica baseada em
medidas calculáveis (diretas) do domínio de informações do software e avaliações
qualitativas da complexidade do software. valores do domínio de informações são
de nidos conforme segue os próximos parágrafos.
Uma vez coletados esses dados, é associado um valor de complexidade com cada
contagem. Organizações que usam métodos ponto de função desenvolvem critérios
para determinar se determinada entrada é simples, média ou complexa. No entanto,
a determinação da complexidade é de certo modo subjetivo.
Para calcular Pontos de Função (PF), usa-se a seguinte relação:
Os F(i= 1 a 14) são fatores de ajuste de valor (value adjustment factors - VAF)
baseados em respostas à questões de ajustes que são feitas ao nal da medição
direta.
Como os casos de uso podem ser criados em níveis muito diferentes de abstração,
não há um “tamanho” padrão para um caso de uso. Sem uma medida padronizada
do que é um caso de uso, sua aplicação como medida de normalização (por
exemplo, esforço gasto por cada caso de uso) é suspeita.
AUTORIA
Ricardo Bortolo Vieira
Segundo o PMBOK (PMI, 2017) as atividades de estimativa são realizadas dentro do
processo de planejamento e são feitas para as áreas de conhecimento: custo,
cronograma e recursos, e contemplam o plano de gerenciamento do projeto - que
servirá como base de consulta para o GP (Gerente de Projeto) tomar suas decisões
durante o projeto. Dentro desse contexto e segundo, as boas práticas de gestão, as
estimativas estão sendo empregadas para criar uma linha de base do projeto, que
servirá de indicador para a gestão do monitoramento e controle do projeto, ou seja,
são estimativas que são usadas internamente para o GP conduzir seu projeto.
E quando o cliente deseja saber qual o custo do projeto que ele pretende aprovar?
Neste caso, o PMBOK (PMI, 2017) recomenda uma visão de projeto chamada de
estimativa de ordem de grandeza (utilizada na fase de Iniciação), onde temos uma
precisão de -25% para menos e + 75% para cima. Isso ainda não é bom para um
tomador de decisão em nível mais baixo dentro da cadeia de decisão de uma
empresa.
Além disso, Huzita (2015) ainda discute a estimativa de custos como um processo do
planejamento e que deve levar em consideração, principalmente, os recursos que
serão utilizados em um projeto de software. A estimativa possui riscos inerentes e
pode ser realizada com maior grau de certeza, quanto maior for a experiência do GP,
quanto maior é o acesso às informações históricas e quanto maior for o empenho
em efetuar previsões quantitativas, mesmo que se tenham apenas dados
qualitativos.
Técnicas de decomposição
Ainda conforme Pressman (2011), a estimativa de projeto de software é uma forma
de solução de problema e, na maioria dos casos, o problema a ser resolvido é muito
complexo para ser considerado em uma única parte. Por essa razão, você deve
decompor o problema, rede nindo-o como uma série de problemas menores.
AUTORIA
Ricardo Bortolo Vieira
Manutenção
Independentemente do domínio de aplicação, tamanho ou complexidade, o
software continuará a evoluir com o tempo. Pressman (2011) estabelece que as
mudanças dirigem esse processo. No âmbito do software, ocorrem alterações
quando são corrigidos erros, quando há adaptação a um novo ambiente, quando o
cliente solicita novas características ou funções e quando a aplicação passa por um
processo de reengenharia para proporcionar benefício em um contexto moderno.
Reengenharia
Reengenharia é um sistema estratégico de reestruturação organizacional e
administrativa, com o objetivo de reformular as atividades de determinada empresa
para que possa se tornar mais competitiva no mercado. A ideia central da
reengenharia é a "reinvenção” (não necessáriamente, mas o processo de repensar e
propor ajustes) da organização, eliminando práticas e costumes que se tornaram
obsoletos e, a partir de estudos e planos, adequar-se aos novos mecanismos de
produção, novas atividades, processos e até mesmo novos produtos.
Reengenharia de Software
Um sistema foi desenvolvido para atender as necessidades de negócio de uma
empresa e perdurou por 20 anos em produção. Durante esse tempo, ele foi
corrigido, adaptado e aperfeiçoado muitas vezes. Pro ssionais realizaram esse
trabalho com as melhores intenções, mas as boas práticas de engenharia de
software foram sempre deixadas de lado, devido à pressão por aspectos de prazo.
Agora o sistema está instável. Ainda funciona, mas sempre que se tenta fazer uma
alteração, ocorrem efeitos colaterais sérios e inesperados. No entanto, o sistema deve
continuar evoluindo. O que fazer?
A ênfase cada vez maior sobre a reengenharia de software foi motivada pelos
problemas de manutenção criados por mais de quatro décadas de esforço de
pesquisa e desenvolvimento de técnicas e processos de desenvolvimento de
software (engenharia de software).
Análise do
inventário
Reestruturação
de documentos
Engenharia
avante
Engenharia
reversa
Reestruturação
dos dados
Reestruturação
do código
REFLITA
“Não se pode administrar o que não se pode medir”, diz Morris A.
Cohen, professor da Wharton e co-diretor do Centro Fishman-Davidson
de Gestão de Serviços e Operações [Fishman-Davidson Center for
Service and Operations Management].
Conclusão - Unidade 4
Outro assunto discutido nesta unidade foi o processo de estimativa de projeto, que
muitas vezes é menosprezado, porém uma estimativa mal feita pode impactar
seriamente os prazos e custos de um projeto.
Durante todo este material, estudamos sobre várias etapas, processos, ferramentas e
técnicas que contemplam o grande arcabouço da Engenharia de Software. Este
material é apenas um conjunto de tópicos dos itens mais importantes dessa grande
área de trabalho. Como cou evidente, independente de sua área de atuação na TI, é
imprescindível que todos tenham este conhecimento para desenvolverem melhor
suas atividades.
Filme
Considerações Finais
Prezado(a) aluno(a),
A partir de agora acreditamos que você já está preparado para seguir em frente
desenvolvendo ainda mais suas habilidades para criar e desenvolver produtos e
marcas de sucesso no mercado e realizar bons negócios. Mas não pare por aqui,
continue estudando e buscando conhecimento. Em nossa área de atuação, sempre
estão sendo lançadas novas ferramentas e técnicas para otimizar e desenvolver
melhor nosso código fonte.