Apostila - Engenharia e Qualidade de Software

Prévia do material em texto

1 
 
 
ENGENHARIA E QUALIDADE DE SOFTWARE 
1 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO ..................................................................................................... 4 
1.1 Engenharia de Software ................................................................................. 4 
1.1.1 Importância dos métodos de desenvolvimento de software .................... 6 
1.2 Ciclo de Vida do Software .............................................................................. 7 
1.2.1 Fase de definição ..................................................................................... 8 
1.2.2 Fase de desenvolvimento ........................................................................ 8 
1.2.3 Fase de operação .................................................................................... 9 
1.2.4 Fase de retirada ..................................................................................... 10 
2. A ESTRUTURA DO PROCESSO DE SOFTWARE ........................................... 10 
2.1 Modelos de Processo ................................................................................... 11 
2.1.1 O modelo cascata .................................................................................. 12 
2.1.2 Modelo Incremental ............................................................................... 13 
2.1.3 Prototipação evolutiva ............................................................................ 14 
2.1.4 Modelo espiral ....................................................................................... 14 
2.1.5 Modelo V................................................................................................ 15 
2.2 Desenvolvimento Ágil ................................................................................... 16 
2.3 Agilidade e Custo das Mudanças ................................................................. 16 
2.4 Processo Ágil ............................................................................................... 17 
2.4.1 Princípios da agilidade ............................................................................... 17 
2.5 Aspectos Humanos da Engenharia de Software e Características .............. 18 
2.6 Psicologia da Engenharia de Software ........................................................ 19 
3. QUALIDADE DE SOFTWARE E GESTÃO DE PROJETOS ............................. 20 
3.1. O Espectro de Gerenciamento ..................................................................... 20 
3.1.1 Pessoas ..................................................................................................... 20 
3.1.2 Produtos .................................................................................................... 21 
3.1.3 Processo .................................................................................................... 21 
3.1.4 Projeto ....................................................................................................... 21 
3.2 Métricas de Processo ................................................................................... 22 
3.2.1 Aperfeiçoamento do processo de software ............................................ 22 
3.3 Estimativas de Projeto de Software .............................................................. 23 
3.3.1 Escopo ....................................................................................................... 24 
3.4 Recursos ...................................................................................................... 24 
3.5 Técnicas de Decomposição ......................................................................... 25 
2 
 
 
3.5.1 Estimativa baseada em linhas de código (LOC) .................................... 26 
3.5.2 Estimativa baseada em pontos de função (FP) ..................................... 26 
3.6 Método COCOMO(Constructive Cost Model)............................................... 28 
3.7 Cronograma de Projetos .............................................................................. 29 
CONSIDERAÇÕES FINAIS ...................................................................................... 31 
REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 32 
 
 
 
3 
 
 
NOSSA HISTÓRIA 
 
 
A nossa história inicia com a realização do sonho de um grupo de empresários, em 
atender à crescente demanda de alunos para cursos de Graduação e Pós-Graduação. Com 
isso foi criado a nossa instituição, como entidade oferecendo serviços educacionais em nível 
superior. 
A instituição tem por objetivo formar diplomados nas diferentes áreas de 
conhecimento, aptos para a inserção em setores profissionais e para a participação no 
desenvolvimento da sociedade brasileira, e colaborar na sua formação contínua. Além de 
promover a divulgação de conhecimentos culturais, científicos e técnicos que constituem 
patrimônio da humanidade e comunicar o saber através do ensino, de publicação ou outras 
normas de comunicação. 
A nossa missão é oferecer qualidade em conhecimento e cultura de forma confiável e 
eficiente para que o aluno tenha oportunidade de construir uma base profissional e ética. 
Dessa forma, conquistando o espaço de uma das instituições modelo no país na oferta de 
cursos, primando sempre pela inovação tecnológica, excelência no atendimento e valor do 
serviço oferecido. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4 
 
 
 
1. INTRODUÇÃO 
 
O software desempenha um papel fundamental em várias áreas de negócios 
seja para controle e segurança de informações, controle de processos, apoio a 
decisões como, também, entretenimento. Há 40 anos, o software começava a se 
tornar complexo e com isso, problemas de qualidade e atendimento de prazos e 
custos já eram apontados. Assim, nasceu a Engenharia de Software tratando o 
software como um produto de engenharia para fazer frente aos novos desafios. 
A Engenharia de Software abrange ferramentas de apoio para as atividades, 
métodos para orientar a realização das atividades, processo para definir as atividades 
e os produtos e a qualidade de processo e de produto de software. Dessa maneira o 
desenvolvimento de software pode obter produtos com qualidade e produtividade. 
 
1.1 Engenharia de Software 
 
O conceito “Engenharia de Software” foi cunhado em 1969 por Fritz Bauer em 
uma conferência patrocinada por um Comitê de Ciência da Organização do Tratado 
do Atlântico Norte (Otan), no momento em que a chamada crise do software precisava 
de uma solução para a demanda crescente por software, dentro de custo e prazo 
adequados. 
Nessa época, a crise foi identificada pela preocupação crescente na 
comunidade de software com a quantidade de defeitos, entregas fora de prazo e altos 
custos do software. De acordo com vários relatos, Fritz Bauer teria dito: 
“A Engenharia de Software é o estabelecimento e uso de sólidos princípios de 
engenharia a fim de obter um software que seja confiável e que funcione de forma 
econômica e eficiente em máquinas reais.” 
É importante notar que a Engenharia de Software segue os mesmos princípios 
de uma disciplina de engenharia tradicional, baseada em uma relação adequada de 
custo/benefício do produto, que não falhe e que seja eficiente. Outras definições 
podem ser encontradas nas normas da IEEE (Institute of Electrical and Electronics 
Engineers) dos Estados Unidos, onde a Engenharia de Software é: 
a) a aplicação de uma abordagem sistemática, disciplinada e quantificável 
para o desenvolvimento, a operação e manutenção de software; 
5 
 
 
b) o estudo de abordagens como descrito em (a). 
Fritz Bauer também declarou que os sistemas deveriam ser construídos em 
níveis e em módulos, que formam uma estrutura matemática. De certa maneira, a 
Engenharia de Software tem evoluído nesta linha e, atualmente, segundo Pressman, 
ela pode ser maisbem entendida como uma tecnologia em camadas ou níveis, 
conforme pode ser vista na Figura 1.1. 
 
 
FIGURA 1.1 Camadas da Engenharia de Software 
 
A engenharia de software é uma tecnologia em camadas. Como ilustra a 
Figura 1.1, qualquer abordagem de engenharia (inclusive engenharia de software) 
deve estar fundamentada em um comprometimento organizacional com a qualidade. 
A gestão da qualidade total promove uma cultura de aperfeiçoamentos contínuo de 
processos, e é essa cultura que, no final das contas, leva ao desenvolvimento de 
abordagens cada vez mais eficazes na engenharia de software. A pedra fundamental 
que sustenta a engenharia de software é o foco na qualidade. 
A base da engenharia de software é a camada de processos. O processo de 
engenharia de software é a liga que mantém as camadas de tecnologia coesas e 
possibilita o desenvolvimento de software de forma racional e dentro do prazo. O 
processo define uma metodologia que deve ser estabelecida para a entrega efetiva 
de tecnologia de engenharia de software. O processo de software constitui a base 
para o controle do gerenciamento de projetos de software e estabelece o contexto no 
qual são aplicados métodos técnicos, são produzidos artefatos (modelos, 
documentos, dados, relatórios, formulários etc.), são estabelecidos marcos, a 
qualidade é garantida e mudanças são geridas de forma apropriada. 
6 
 
 
Os métodos da engenharia de software fornecem as informações técnicas 
para desenvolver softwares. Os métodos envolvem uma ampla variedade de tarefas, 
que incluem: comunicação, análise de requisitos, modelagem de projeto, construção 
de programa, testes e suporte. Os métodos da engenharia de software se baseiam 
em um conjunto de princípios básicos que governam cada área da tecnologia e 
incluem atividades de modelagem e outras técnicas descritivas. 
As ferramentas da engenharia de software fornecem suporte automatizado ou 
semiautomatizado para o processo e para os métodos. Quando as ferramentas são 
integradas, de modo que as informações criadas por uma ferramenta possam ser 
utilizadas por outra, é estabelecido um sistema para o suporte ao desenvolvimento de 
software, denominado engenharia de software com o auxílio do computador. 
 
 
 
1.1.1 Importância dos métodos de desenvolvimento de software 
 
A importância dos métodos de desenvolvimento de software advém do fato de 
que eles definem, por meio de suas notações, um canal de comunicação uniforme 
entre os membros da equipe de desenvolvimento. Também, os métodos estabelecem 
produtos de trabalho padronizados que facilitam as atividades de manutenção de 
software. Além disso, permitem que novos colaboradores sejam treinados melhorando 
a qualidade do software. Os métodos podem ser usados como referência para a 
escolha e aquisição de ferramentas CASE (do inglês Computer-Aided Software 
Engineering, é uma classificação que abrange todas as ferramentas baseadas em 
computadores que auxiliam atividades de engenharia de software, desde análise de 
requisitos e modelagem até programação e testes) que podem dar maior 
produtividade ao processo de desenvolvimento de software. 
 INFORMATIVO 
A disciplina de Engenharia de Software é muito abrangente. Processos, 
métodos, técnicas e ferramentas têm sido propostos com frequência. Esta 
contínua evolução da Engenharia de Software aponta para a necessidade 
de melhorar as abordagens atuais para produzir softwares cada vez mais 
complexos com qualidade e produtividade. 
7 
 
 
Tais métodos vêm sendo desenvolvidos desde o início da definição da 
Engenharia de Software e, atualmente, muitos desses métodos estão consolidados 
na comunidade de software. Atualmente, duas abordagens são reconhecidas: 
Estruturada e Orientada a Objetos, que são discutidas no próximo tópico. 
 
 
 
1.2 Ciclo de Vida do Software 
 
 Todo projeto de software começa por alguma necessidade do negócio, a 
necessidade de corrigir um defeito em uma aplicação existente. Para entender de 
software precisamos analisar as características do software que o tornam diferente de 
outras coisas produzidas. O software é um elemento de um sistema lógico e não de 
um sistema físico. Assim ele possui características que são consideravelmente 
diferentes daquelas do hardware: 
 O Software é desenvolvido ou passa por um processo de engenharia; não é 
fabricado no sentido clássico; 
 Software não se desgasta; 
 Apesar de a indústria estar se movendo em direção à montagem baseada em 
componentes, a maior parte dos softwares continua a ser construída sob encomenda. 
O ciclo de vida de um software descreve as fases pelas quais o software passa 
desde a sua concepção até ficar sem uso algum. O conceito de ciclo de vida de um 
software é muitas vezes confundido com o de modelo de processo. Existem várias 
propostas e denominações para as fases do ciclo de vida de um software. Cada fase 
inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes 
envolvidas. Essas fases são: 
 SUGESTÃO DE LEITURA 
 BOURQUE Pierre, DUPUIS Robert, TRIPP Leonard L. Guide to the 
software engineering body of knowledge – SWEBOK. USA: IEEE 
Computer Society Press; 2004. 
 PFLEEGER Shari L. Software engineering: theory and practice. 2 New 
Jersey: Prentice Hall; 2001. 
8 
 
 
 Definição 
 Desenvolvimento 
 Operação 
 Retirada 
 
1.2.1 Fase de definição 
 
 A fase de definição do software ocorre em conjunto com outras atividades como 
a modelagem de processos de negócios e análise de sistemas. Nesta atividade, se 
concentra a busca pelo conhecimento da situação atual e a identificação de problemas 
para a elaboração de propostas de solução de sistemas computacionais que resolvam 
tais problemas. 
 Profissionais de engenharia de software atuam nesta atividade com o objetivo 
de identificar os requisitos de software e modelos de domínio que serão utilizados na 
fase de desenvolvimento. 
 
1.2.2 Fase de desenvolvimento 
 
 A fase de desenvolvimento ou de produção do software inclui todas as 
atividades que tem por objetivo a construção do produto. Ela inclui principalmente o 
design, a implementação e a verificação e validação do software. 
 A atividade de design compreende todo o esforço de concepção e modelagem 
que têm por objetivo descrever como o software será implementado. 
 A implementação envolve as atividades de codificação, compilação, integração 
e testes. A codificação visa traduzir o design num programa, utilizando linguagens e 
ferramentas adequadas. A codificação deve refletir a estrutura e o comportamento 
descrito no design. Os componentes arquiteturais devem ser codificados de forma 
independente e depois integrados. Os testes podem ser iniciados durante a fase de 
implementação. A depuração de erros ocorre durante a programação utilizando 
algumas técnicas e ferramentas. É fundamental um controle e gerenciamento de 
versões para que se tenha um controle correto de tudo o que está sendo codificado. 
 Verificação e validação destinam-se a mostrar que o sistema está de acordo 
com a especificação e que ele atende às expectativas de clientes e usuários. A 
9 
 
 
validação visa assegurar se o programa está fazendo aquilo que foi definido na sua 
especificação (fazendo a coisa certa). 
 Existem diferentes formas de verificação e validação. Inspeção analítica e 
revisão de modelos, documentos e código fonte são formas que podem ser usadas 
antes mesmo que o programa seja completamente codificado. Os testes de correção, 
desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar 
diversos fatores de qualidade a partir da execução do software. 
 
1.2.3 Fase de operação 
 
 A fase de operação envolve diferentes tipos de atividades: 
 Distribuição e entrega 
 Instalação e configuração 
 Utilização 
 Manutenção 
A distribuição e entrega pode ser feita diretamente pelo desenvolvedor(em 
caso de software personalizado), ou em um pacote a ser vendido em prateleiras de 
lojas ou para ser baixado pela Internet (em caso de softwares genéricos). 
 O processo de instalação e configuração, normalmente, pode ser feito com a 
ajuda de software de instalação disponibilizados pelos fabricantes dos ambientes 
operacionais. 
A atividade de utilização é o objeto do desenvolvimento do software. A 
qualidade da utilização é a usabilidade do software. 
A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A 
manutenção corretiva visa a resolução de problemas referentes a qualidade do 
software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade, etc.). 
A manutenção evolutiva ou adaptativa visa a produção de novas versões do software 
de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas tecnologias 
que surgem (hardware, plataformas operacionais, linguagens, etc.). Mudanças no 
domínio de aplicação implicam em novos requisitos e incorporação de novas 
funcionalidades. Surgimento de novas tecnologias de software e hardware e 
mudanças para uma plataforma mais avançada também requerem evolução. 
 
 
10 
 
 
 
 
1.2.4 Fase de retirada 
 
 A fase de retirada é um grande desafio para os tempos atuais. Diversos 
softwares que estão em funcionamento em empresas possuem excelentes níveis de 
confiabilidade e de correção. No entanto, eles precisam evoluir para novas 
plataformas operacionais ou para a incorporação de novos requisitos. A retirada desse 
software legado em uma empresa é sempre uma decisão difícil: como abrir mão 
daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de 
treinamento e utilização? 
 Processos de reengenharia podem ser aplicados para viabilizar a transição ou 
migração de um software legado para um novo software de forma a proporcionar uma 
retirada mais suave. 
 
 
 
2. A ESTRUTURA DO PROCESSO DE SOFTWARE 
 
O processo de software está́ representado esquematicamente na Figura 2. De 
acordo com a figura, cada atividade metodológica é composta por um conjunto de 
ações de engenharia de software. Cada ação é definida por um conjunto de tarefas, o 
qual identifica as tarefas de trabalho a ser completadas, os artefatos de software que 
serão produzidos, os fatores de garantia da qualidade que serão exigidos e os marcos 
utilizados para indicar progresso. 
Uma metodologia de processo genérica para engenharia de software 
estabelece cinco atividades metodológicas: comunicação, planejamento, 
modelagem, construção e entrega. Além disso, um conjunto de atividades de apoio 
é aplicado ao longo do processo, como o acompanhamento e controle do projeto, a 
administração de riscos, a garantia da qualidade, o gerenciamento das configurações, 
as revisões técnicas, entre outras. 
11 
 
 
 
Figura 2 - Uma metodologia do processo de software 
 
2.1 Modelos de Processo 
 
Um modelo de processo prescritivo concentra-se em estruturar e ordenar o 
desenvolvimento de software. As atividades e tarefas ocorrem sequencialmente, com 
diretrizes de progresso definidas. Mas os modelos prescritivos são adequados para o 
mundo do software que se alimenta de mudanças? Se rejeitarmos os modelos de 
processo tradicionais (e a ordem implícita) e os substituirmos por algo menos 
estruturado, tornaremos impossível atingir a coordenação e a coerência no trabalho 
de software? 
12 
 
 
Não há respostas fáceis para essas questões, mas existem alternativas 
disponíveis para os engenheiros de software. Nas próximas seções, examinamos a 
abordagem dos processos prescritivos, nos quais a ordem e a consistência do projeto 
são questões predominantes. Chamamos esses processos de “prescritivos” porque 
prescrevem um conjunto de elementos de processo: atividades metodológicas, ações 
de engenharia de software, tarefas, artefatos, garantia da qualidade e mecanismos de 
controle de mudanças para cada projeto. Cada modelo de processo também 
prescreve um fluxo de processo (também denominado fluxo de trabalho) ou seja, a 
forma pela qual os elementos do processo estão relacionados. 
 
2.1.1 O modelo cascata 
 
Há casos em que os requisitos de um problema são bem compreendidos, 
quando o trabalho flui da comunicação à disponibilização de modo relativamente 
linear. O modelo cascata, algumas vezes chamado ciclo de vida clássico, sugere uma 
abordagem sequencial e sistemática para o desenvolvimento de software, começando 
com a especificação dos requisitos do cliente, avançando pelas fases de 
planejamento, modelagem, construção e disponibilização, e culminando no suporte 
continuo do software concluído. 
 
 
Figura 2.1.1 – Modelo Cascata 
 
O modelo cascata é o paradigma mais antigo da engenharia de software. 
Entretanto, ao longo das últimas quatro décadas, as críticas a este modelo de 
processo fizeram até mesmo seus mais árduos defensores questionarem sua eficácia. 
Entre os problemas às vezes encontrados quando se aplica o modelo cascata, temos: 
 
 
13 
 
 
 Projetos reais raramente seguem o fluxo sequencial proposto pelo modelo. 
Embora o modelo linear possa conter iterações, ele o faz indiretamente. Como 
consequência, mudanças podem provocar confusão à medida que a equipe de projeto 
prossegue. 
 Frequentemente, é difícil para o cliente estabelecer explicitamente todas as 
necessidades. O modelo cascata exige isso e tem dificuldade para adequar a 
incerteza natural existente no início de muitos projetos. 
 O cliente deve ter paciência. Uma versão operacional do(s) programa(s) não 
estará disponível antes de estarmos próximos ao final do projeto. Um erro grave, se 
não detectado até o programa operacional ser revisto, pode ser desastroso. 
 
2.1.2 Modelo Incremental 
 
Há várias situações em que os requisitos iniciais do software são 
razoavelmente bem definidos; entretanto, o escopo geral do trabalho de 
desenvolvimento, impede o uso de um processo puramente linear. Pode ser 
necessário o rápido fornecimento de determinado conjunto funcional aos usuários 
para, somente após esse fornecimento, refinar e expandir sua funcionalidade em 
versões de software posteriores. Em tais casos, pode-se optar por um modelo de 
processo projetado para desenvolver o software de forma incremental. 
O modelo incremental combina os fluxos de processo linear e paralelo dos 
elementos. Na Figura 2.1.2, o modelo incremental aplica sequências lineares de forma 
escalonada, à medida que o tempo vai avançando. 
 
Figura 2.1.2 – Modelo incremental 
14 
 
 
2.1.3 Prototipação evolutiva 
 
Frequentemente, o cliente define uma série de objetivos gerais para o 
software, mas não identifica, detalhadamente, os requisitos para funções e recursos. 
Em outros casos, o desenvolvedor se encontra inseguro quanto à eficiência de um 
algoritmo, quanto à adaptabilidade de um sistema operacional ou quanto à forma em 
que deve ocorrer a interação homem máquina. Em situações como essas, e em muitas 
outras, o paradigma da prototipação pode ser a melhor abordagem. 
Na sua forma ideal, o protótipo atua como um mecanismo para identificar os 
requisitos do software. Caso seja necessário desenvolver um protótipo operacional, 
pode-se utilizar partes de programas existentes ou aplicar ferramentas que 
possibilitem gerar rapidamente tais programas operacionais. 
 
Figura 2.1.3 – Modelo de prototipação evolutiva 
 
2.1.4 Modelo espiral 
 
O modelo espiral é um modelo de processo de software evolucionário que une 
a natureza iterativa da prototipação aos aspectos sistemáticos e controlados do 
modelo cascata. Tem potencial para o rápido desenvolvimento de versões cada vez 
mais completas do software. 
O primeiro circuito em volta da espiral pode resultar no desenvolvimento de 
uma especificação de produto; passagens subsequentes em torno da espiral podem 
ser usadas para desenvolver um protótipo e, então,progressivamente, versões cada 
vez mais sofisticadas do software. Cada passagem pela região de planejamento 
resulta em ajustes no planejamento do projeto. Custo e cronograma são ajustados de 
15 
 
 
acordo com o feedback (a realimentação) obtido do cliente após a entrega. Além disso, 
o gerente de projeto faz um ajuste no número de iterações planejadas para concluir o 
software. 
 
Figura 2.1.4 – Modelo espiral 
 
2.1.5 Modelo V 
 
O Modelo V é similar ao processo Cascata, com a diferença de que este 
modelo está preocupado com o planejamento dos testes nas fases de 
desenvolvimento. Cada tipo de teste é realizado seguindo um plano de testes 
correspondente, verificando e validando se as especificações definidas nas fases de 
desenvolvimento estão sendo atendidas. Seguindo a característica sequencial do 
processo Cascata, um teste de mais alto nível é realizado somente se o teste atual for 
bem-sucedido. De forma geral, o Modelo V não é tão conhecido como o processo 
Cascata, mas pela sua simplicidade e melhor organização das atividades de teste ele 
se torna um processo bastante interessante para disseminar a importância dos testes 
no processo de desenvolvimento de software. 
16 
 
 
 
Figura 2.1.5 – Modelo V 
 
2.2 Desenvolvimento Ágil 
 
Em 2001, Kent Beck e outros 16 renomados desenvolvedores, autores e 
consultores da área de software (batizados de “Agile Alliance” – “Aliança dos Ágeis”) 
assinaram o “Manifesto para o Desenvolvimento Ágil de Software” (“Manifesto for 
Agile Software Development”). Ele declarava: 
Ao desenvolver e ajudar outros a desenvolver softwares, desvendamos formas 
melhores de desenvolvimento. Por meio deste trabalho passamos a valorizar: 
 Indivíduos e interações acima de processos e ferramentas. 
 Software operacional acima de documentação completa. 
 Colaboração dos clientes acima de negociação contratual. 
 Respostas a mudanças acima de seguir um plano. 
Ou seja, embora haja valor nos itens à direita, valorizaremos os da esquerda 
mais ainda. 
 
2.3 Agilidade e Custo das Mudanças 
 
O pensamento convencional em desenvolvimento de software (baseada em 
décadas de experiência) é que os custos de mudanças aumentam de forma não linear 
conforme o projeto avança. 
Os proponentes da agilidade argumentam que um processo ágil bem 
elaborado “achata” o custo da curva de mudança (Figura 2.3 curva em linha azul), 
17 
 
 
permitindo que uma equipe de software assimile as alterações, realizadas 
posteriormente em um projeto de software, sem um impacto significativo nos custos 
ou no tempo. 
 
 
Figura 2.3 – Custos de alterações como uma função do tempo em desenvolvimento 
 
2.4 Processo Ágil 
 
Processo ágil de software é caracterizado de uma forma que trate de uma 
série de preceitos chaves acerca da maioria dos projetos de software. Adaptação 
continua sem progressos, entretanto, de pouco adianta. Um processo ágil de software 
deve adaptar de modo incremental. Para conseguir uma adaptação incremental, a 
equipe ágil precisa de feedback do cliente (de modo que as adaptações apropriadas 
possam ser feitas). 
 
2.4.1 Princípios da agilidade 
 
A Agile Alliance estabelece 12 princípios para alcançar a agilidade: 
1. A maior prioridade é satisfazer o cliente com entrega adiantada e continua de 
software funcionando. 
2. Aceite bem os pedidos de alterações, mesmo com o desenvolvimento 
adiantado. Os processos ágeis se aproveitam das mudanças para a vantagem 
competitiva do cliente. 
3. Entregue software em funcionamento frequentemente, de algumas sema- nas 
a alguns meses, dando preferência a intervalos mais curtos. 
18 
 
 
4. O pessoal do comercial e os desenvolvedores devem trabalhar em con- junto 
diariamente ao longo de todo o projeto. 
5. Construa projetos em torno de pessoas motivadas. Dê a elas o ambiente e o 
apoio necessários e acredite que elas farão o trabalho corretamente. 
6. O método mais eficiente e efetivo de transmitir informações para e dentro de 
uma equipe de desenvolvimento é uma conversa aberta, presencial. 
7. Software em funcionamento é a principal medida de progresso. 
8. Os processos ágeis promovem desenvolvimento sustentável. Proponentes, 
desenvolvedores e usuários devem estar aptos a manter um ritmo constante 
indefinidamente. 
9. Atenção contínua para com a excelência técnica e para com bons projetos 
aumenta a agilidade. 
10. Simplicidade, a arte de maximizar o volume de trabalho não realizado é 
essencial. 
11. As melhores arquiteturas, requisitos e projetos surgem de equipes auto-
organizadas. 
12. Em intervalos regulares, a equipe se avalia para ver como pode se tornar 
mais eficiente, então, sintoniza e ajusta seu comportamento de acordo. 
 
2.5 Aspectos Humanos da Engenharia de Software e Características 
 
Então você quer ser engenheiro de software? Obviamente, precisa dominar o 
material técnico, aprender e aplicar as habilidades exigidas para entender o problema, 
projetar uma solução eficaz, construir o software e testá-lo com a finalidade de 
produzir a mais alta qualidade possível. Você̂ precisa gerenciar mudanças, comunicar-
se com os envolvidos e usar ferramentas adequadas nas situações apropriadas. 
Um engenheiro de software competente tem um senso de responsabilidade 
individual. Significa que ele fará o que precisar ser feito, quando for necessário, 
executando um esforço adicional para a obtenção de um resultado bem-sucedido. 
Um engenheiro de software competente tem elevado senso de lealdade. De 
boa vontade, compartilha os créditos com seus colegas. Tenta evitar conflitos de 
interesse e nunca age no sentido de sabotar o trabalho dos outros. 
Um engenheiro de software competente mostra atenção aos detalhes. Isso 
não significa obsessão com a perfeição, mas sugere que ele considera atentamente 
19 
 
 
as decisões técnicas que toma diariamente, em comparação com critérios mais 
amplos (por exemplo, desempenho, custo, qualidade) que foram estabelecidos para 
o produto e para o projeto. 
Por último, um engenheiro de software competente é pragmático. Reconhece 
que a engenharia de software não é uma religião na qual devem ser seguidas regras 
dogmáticas, mas sim uma disciplina que pode ser adaptada de acordo com as 
circunstâncias. 
 
2.6 Psicologia da Engenharia de Software 
 
Nos níveis da equipe e do projeto, dinâmicas de grupo se tornam o fator 
dominante. Aqui, a estrutura da equipe e fatores sociais governam o sucesso. A 
comunicação, a colaboração e a coordenação do grupo são tão importantes quanto 
as habilidades dos membros individuais da equipe. Nas camadas externas, o 
comportamento organizacional governa as ações da empresa e sua resposta para o 
meio empresarial. 
 
 
Figura 2.6 – Modelo comportamental em camadas 
 
 
 
 
 
20 
 
 
3. QUALIDADE DE SOFTWARE E GESTÃO DE PROJETOS 
 
A gestão de projetos define quem, o que, quando e o porquê dos projetos. Ela 
faz uso de processos e ferramentas de gestão os quais servem para ajudar o gerente 
de projetos e equipe a organizar, documentar, rastrear e relatar as atividades e 
progresso de um projeto. Dentro desse contexto, o plano de projeto compreende: 
 Escopo de projeto bem definido; 
 Documentação e responsabilidades dos participantes; 
 Uma linguagem comum para comunicação das atividades do projeto, bem 
como a rastreabilidade e relatórios dessas atividades; 
 Mecanismos de resolução de conflitos e mitigação ou atenuação de riscos. 
 
3.1. O Espectro de Gerenciamento 
 
O gerenciamento eficiente do desenvolvimento de software se concentra nos 4 
Ps: pessoas, produto, processo e projeto. Essa ordem não é arbitrária. O gerente que 
se esquecer de que o trabalho do engenheiro de software consiste em esforço humano 
nunca terá́ sucesso no gerenciamento de projeto. Da mesma forma, o que não 
estimula a ampla comunicação entre os envolvidos no início da evolução de um 
produtocorre o risco de desenvolver uma solução elegante para o problema errado. 
Um gerente que preste pouca atenção ao processo se arrisca a inserir métodos e 
ferramentas técnicas competentes em um vácuo. Aquele que embarca sem um plano 
de projeto sólido compromete o sucesso do projeto. 
 
3.1.1 Pessoas 
 
Desde os anos 1960, debate-se a valorização da cultura de ter pessoal de 
desenvolvimento motivado e de alto nível. Realmente, recursos humanos é um fator 
de tal importância que o Software Engineering Institute (SEI) desenvolveu um Modelo 
de Maturidade de Capacitação de Pessoas, o People-CMM (People Capability 
Maturity Model) - em reconhecimento ao fato de que: “Toda organização precisa 
aprimorar continuamente sua habilidade de atrair, desenvolver, motivar, organizar e 
reter a forca de trabalho necessária para atingir os objetivos estratégicos de seus 
negócios” 
21 
 
 
3.1.2 Produtos 
 
Antes de traçarmos um plano de projeto, devemos estabelecer os objetivos 
do produto e seu escopo, considerar as soluções alternativas e identificar as restrições 
técnicas e de gerenciamento. Sem essas informações, é impossível definir de modo 
razoável (e preciso) a estimativa de custo, a avaliação efetiva dos riscos, a análise 
realista das tarefas do projeto ou um cronograma gerenciável do projeto que forneça 
a indicação significativa de progresso das atividades. 
 
3.1.3 Processo 
 
 Um processo de software fornece a metodologia por meio da qual pode ser 
estabelecido um plano de projeto abrangente para o desenvolvimento de software. 
Uma quantidade de diferentes conjuntos de atividades e tarefas, pontos de controle, 
artefatos de software e pontos de garantia de qualidade possibilitam que as atividades 
metodológicas sejam adaptadas às características do projeto de software e aos 
requisitos de equipe. 
 
3.1.4 Projeto 
 
 Conduzimos projetos com planejamento e com controle por uma única e 
principal razão: é a única maneira de administrar a complexidade. E, mesmo assim, 
as equipes de software têm de se esforçar. Em um estudo de 250 grandes projetos 
de software entre 1998 e 2004, Carpe Jones constatou que “perto de 25 obtiveram 
sucesso em cumprir cronograma, custos e objetivos quanto à qualidade. Em torno de 
50 apresentaram atrasos ou retardamentos abaixo de 35%, enquanto 175 projetos 
tiveram atrasos e retardamentos sérios ou não foram concluídos”. 
 Em um trabalho sobre processo e projetos de software, Barry Boehm, sugere 
uma abordagem com foco nos objetivos do projeto, marcos e cronogramas, 
responsabilidades, abordagens gerenciais e técnicas, e recursos necessários. Ele 
denomina o princípio W5HH: 
22 
 
 
 
Figura 3.1.4 – W5HH 
 
3.2 Métricas de Processo 
 
A medição é uma ferramenta de gerenciamento. Se for usada adequada- 
mente, ela aumenta o conhecimento do gerente de projeto. E, consequentemente, 
ajuda o gerente de projeto e a equipe de software a tomarem decisões que levarão a 
um projeto bem-sucedido. 
 
3.2.1 Aperfeiçoamento do processo de software 
 
Métricas de processo são coletadas em todos os projetos e no decorrer de 
longos períodos de tempo. Sua finalidade é proporcionar um conjunto de indicadores 
de processo que levam à melhoria do processo de software no longo prazo. A única 
maneira lógica de melhorar qualquer processo é medir atributos específicos do 
processo, desenvolver um conjunto de métricas significativas com base nesses 
atributos e então usar as métricas para fornecer indicadores que levem a uma 
estratégia de aperfeiçoamento. 
23 
 
 
 
Figura 3.2.1 – Determinantes para a qualidade do software 
 
O processo está́ no centro do triângulo que conecta três fatores de profunda 
influência sobre a qualidade do software e do desempenho organizacional. A 
complexidade do produto pode ter um impacto significativo sobre a qualidade e o 
desempenho da equipe. A tecnologia (isto é, os métodos e ferramentas de engenharia 
de software) que preenche o processo também tem um impacto. 
 
3.3 Estimativas de Projeto de Software 
 
O gerenciamento do projeto de software começa com um conjunto de 
atividades chamadas coletivamente de planejamento de projeto. Antes de iniciar o 
projeto, a equipe de software deve fazer uma estimativa do trabalho, dos recursos que 
serão necessários e do tempo necessário para a sua conclusão. Uma vez cumpridas 
essas atividades, a equipe de projeto deve estabelecer um cronograma que defina as 
tarefas e as metas de engenharia de software, deve identificar os responsáveis pela 
execução de cada tarefa e deve especificar as dependências entre tarefas que podem 
ter forte influência no progresso do trabalho. 
 
 
 
24 
 
 
3.3.1 Escopo 
 
O escopo do software descreve as funções e características que devem ser 
fornecidas aos usuários; os dados que entram e saem, o “conteúdo” que é 
apresentado aos usuários como consequência do uso do software e o desempenho, 
restrições, interfaces e confiabilidade que limitam o sistema. O escopo é definido por 
meio de uma das duas técnicas: 
 Uma descrição narrativa do escopo do software é desenvolvida após 
comunicação com todos os envolvidos. 
 Um conjunto de casos de uso é desenvolvido pelos usuários. 
Funções descritas na definição do escopo (ou nos casos de uso) são avaliadas 
e, em algumas situações, refinadas para fornecer mais detalhes, antes de iniciar as 
estimativas. Como as estimativas de custo e cronograma são ambas funcionalmente 
orientadas, muitas vezes é aconselhável certo grau de separação. As considerações 
de desempenho abrangem requisitos de processamento e tempo de resposta. As 
restrições identificam limites colocados no software por hardware externo, memória 
disponível ou outros sistemas existentes. 
 
3.4 Recursos 
 
O planejador começa avaliando o escopo do software e selecionando as 
habilidades necessárias para concluir o desenvolvimento. São especificados o cargo 
(por exemplo, gerente, engenheiro de software sênior) e a especialização (por 
exemplo, telecomunicações, banco de dados, cliente-servidor). Para projetos 
relativamente pequenos (poucas pessoas/mês), um só profissional pode executar 
todas as tarefas de engenharia de software, consultando os especialistas quando 
necessário. Para projetos maiores, a equipe pode estar geograficamente dispersa em 
diferentes locais. Portanto, é especificada a localização de cada recurso humano. 
25 
 
 
 
Figura 3.4 – Recursos de projeto 
 
3.5 Técnicas de Decomposição 
 
Desenvolver uma estimativa de custo e esforço para um projeto de software 
é muito complexo para ser considerado como um todo. Por essa razão devemos 
decompor o problema, caracterizando-o como um conjunto de problemas menores. 
 No contexto do planejamento de projeto, o tamanho refere-se ao resultado 
quantificável do projeto de software. Se uma abordagem direta é adotada, o tamanho 
pode ser medido em linhas de código (LOC). Se uma abordagem indireta é escolhida, 
o tamanho é representado como pontos por função (FP). Dados de LOC e FP são 
usados de dois modos durante a estimativa de projetos de software: 
1. Como variável de estimativa para “dimensionar” cada elemento de 
software; 
2. Como métricas referenciais coletadas de projetos anteriores e usadas 
juntamente com variáveis de estimativa para desenvolver projeções de custo e 
esforço. 
Quando um novo projeto é estimado, deve ser primeiro classificado em um 
domínio (tamanho de equipe, área de aplicação, complexidade e outros parâmetros 
relevantes) e depois a média de produtividade do domínio adequado deve ser usada 
para gerar a estimativa. 
 
26 
 
 
3.5.1 Estimativa baseada em linhas de código (LOC) 
 
A medida mais simples para tamanho de um programa é a contagem de linhas 
de código. Existem algumas variantes para ela, como LOC (Lines Of Code), SLOC 
(Source Lines Of Code) lógico e SLOC físico. 
O método mais simplese também o mais impreciso: utilizando-se LOC não se 
distingue linhas de código de linhas em branco ou de comentários. Essa métrica é, 
em princípio, o padrão indicado para uso no PSP (Personal Software Process). Pode 
ser suficientemente precisa quando se comparam grandes volumes de código: 
naturalmente, um programa de 4 KLOC (milhares de linhas) deve ser mais complexo 
e levar mais tempo para ser desenvolvido que outro de 2 KLOC. Para aumentar a 
precisão da medida, sugeriu-se o uso do SLOC, onde linhas em branco ou com 
comentários não são consideradas. As variantes “lógica” e “física” não têm definições 
amplamente padronizadas. O exemplo abaixo seria medido como três LOCs, dois 
SLOCs físicos e três SLOCs lógicos: 
 
//uma verificação 
IF (a > b) {a++; var (“ok”); 
} 
 
3.5.2 Estimativa baseada em pontos de função (FP) 
 
Como vimos, a medida LOC é simples e por esse motivo também é imprecisa. 
Um programador gastaria no máximo alguns minutos para juntar os arquivos-fonte de 
um projeto e obter do editor a contagem total de linhas. Entretanto o número obtido 
não revelaria nada a propósito da estrutura de tal sistema. 
Para determinar o número de FPs, deve-se considerar a contagem de dados e 
de transações. Na contagem de dados, consideram-se arquivos lógicos internos ou 
arquivos de interface externos. Entre as transações têm-se entradas externas, saídas 
externas ou consultas externas. 
O termo arquivo refere-se a um grupo de dados logicamente relacionados: 
 Arquivos lógicos internos (ALI): São relativos às funcionalidades do software, 
como, por exemplo, cadastro de clientes e alteração de produtos. Não são ALI, por 
exemplo, arquivos temporários e de classificação; 
27 
 
 
 Arquivos de interface externos (ALE): Os dados são mantidos e/ou alimentados 
por outros programas. As transações representam as funcionalidades providas ao usuário 
pelo processamento dos dados em um software; 
 Entradas externas (EE): Processo lógico onde dados são introduzidos no sistema. 
Os dados podem ser informações de controle ou de negócios. Por exemplo, exclusão, 
alteração e inclusão de registros; 
 Saídas externas (SE): Processo lógico em que dados são enviados ao exterior das 
fronteiras do sistema. Por exemplo, um relatório ou mesmo a apresentação dos dados em 
tela; 
 Consulta Externa (CE): Os dados são recuperados exclusivamente de arquivos 
internos e interfaces externas (nada é computado). Por exemplo, consulta ao cadastro de 
cliente. 
Após terem sidos identificados e contados, esses cinco fatores devem ter sua 
complexidade classificada como baixa, média ou alta. Essa classificação depende de 
uma análise dos elementos de dados que compõe cada fator. Cada organização deve 
padronizar seu método de classificação de complexidade. 
Dois programas distintos podem ter a mesma contagem de pontos de função. 
Aspectos como complexidade dos cálculos ou requisitos como tempo real não entram 
no cálculo, até então. Para resolver isso pode ser utilizada uma técnica conhecida 
como Fator de Ajuste, que é baseada em 14 características gerais do sistema: 
1. Comunicação de Dados; 
2. Funções distribuídas; 
3. Desempenho; 
4. Configuração do equipamento; 
5. Volume de transações; 
6. Entrada de dados on-line; 
7. Interface com o usuário; 
8. Atualização on-line; 
9. Processamento complexo; 
10. Reusabilidade; 
11. Facilidade de implantação; 
12. Facilidade operacional 
13. Múltiplos locais; 
14. Flexibilidade de mudanças. 
 
28 
 
 
Cada CGS possui um nível de influência de 0 a 5, e é calculado por: FA = 0.65 
+ 0.01 X (n1 + n2 + ... + n14). 
Onde cada ni representa um dos 14 níveis de influência. A partir do valor do 
FA, pode-se calcular o número de pontos de função ajustados (PFA): PFA = FA x PF 
Algumas métricas podem ser derivadas a partir do cálculo de pontos de função, 
como o número de homens/hora para produzir 1PF (ou 1PFA, Ponto de Função 
Ajustado) ou, ainda, dada a produtividade média da equipe, o tempo necessário para 
implementar um projeto. 
Por exemplo, se uma equipe produz em média 10 PFs por dia, um projeto cujo 
tamanho é 300 PFs deve ser implementado em um mês. De maneira semelhante 
pode-se aproximar valores para o preço de um produto, a partir do custo de 
desenvolvimento de 1PF dentro da organização. 
 
3.6 Método COCOMO(Constructive Cost Model) 
 
Uma das tarefas mais difíceis de um projeto é a correta aplicação dos recursos 
(humanos) durante seu desenvolvimento, ou seja, em que momento precisarei de 
mais ou menos programadores/analistas. 
O método COCOMO nada mais é do que uma pesquisa feita em centenas de 
empresas norte-americanas que mapeou a distribuição do esforço durante as fases 
de um projeto. Os principais números são: 
 
 
Figura 3.6 – Método COCOMO 
 
 
 
 
 
 
29 
 
 
 
Um tempo total de 875h aplicados ao método, ficaria: 
 
 Figura 3.6.1 – Método COCOMO aplicado 
 
Assim sendo distribui-se essas horas nos recursos, em um cronograma, 
conforme estratégia da gerência e também levando em conta os prazos finais 
estabelecidos pelo usuário. 
 
3.7 Cronograma de Projetos 
 
O cronograma de projeto de software é uma atividade que distribui o esforço 
estimado pela duração planejada do projeto, partilhando esse esforço por tarefas 
específicas de engenharia de software. É importante notar que o cronograma evolui 
com o tempo. Durante os primeiros estágios do planejamento do projeto, um 
cronograma macro é desenvolvido. Esse cronograma identifica todas as principais 
atividades do processo e as funções do produto a que se aplicam à medida que o 
projeto avança, cada entrada nesse cronograma é refinada em um cronograma 
detalhado. 
 O exemplo a seguir refere-se a um cronograma de desenvolvimento de um 
projeto novo. Informações como atividades macro, atividades refinadas e suas 
respectivas datas são exibidas. Em um cronograma é importante que para cada 
atividade sejam definidas datas inicial e final. 
30 
 
 
 
 Figura 3.7 - Cronograma de projetos 
 
 
31 
 
 
CONSIDERAÇÕES FINAIS 
 
As tecnologias de software e de sistemas continuam a ser um desafio para 
todo profissional de software e toda empresa que constrói sistemas de computador. 
Uma coisa que aprendemos durante muitos anos nesse campo é que os profissionais 
de engenharia de software são “conscientes de sua situação”. O caminho à frente 
estará entulhado de carcaças de novas e excitantes tecnologias (a última moda) que 
nunca tiveram sucesso (apesar da quantidade de “novidades”). O futuro será formado 
por tecnologias mais modestas que, de certa forma, modificam a direção e a amplitude 
do caminho. 
As aplicações das técnicas em estudo visam a melhora contínua do software 
e sua adaptabilidade dentro do que foi planejado e como profissionais, os engenheiros 
de software devem se orientar por um código de ética que rege o trabalho que fazem 
e os produtos que criam, garantindo um planejamento adequado, minimizando os 
riscos e potencializando as chances de sucesso. 
 
 
 
32 
 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
 
ENGENHARIA DE SOFTWARE: revista de engenharia de software. Rio de Janeiro: 
Grupo Devmedia, 2008. 
 
EVELEENS J Laurenz, VERHOEF Chris. The rise and fall of the chaos report figures. 
IEEE Software. 2010. 
 
FILHO, Wilson de Pádua Paula. Engenharia de Software, Fundamentos, Métodos 
e Padrões. Rio de Janeiro: LTC – Livros Técnicos e Científicos Editora S.A. 2003. 
 
OLIVEIRA, Jayr Figueiredo de. Metodologia para Desenvolvimento de Projetos de 
Sistemas – Guia prático. 3. Edição revisada em ampliada. São Paulo : Érica, 1999. 
 
PRESSMANN, Roger S. Engenharia de Software São Paulo : Makron Books, 6. Ed. 
2006 : McGraw-Hill 2006. 
 
SOMMERVILLE, I. Engenharia de Software. 8a Edição. Addison Wesley. 2007. 
PRESSMAN Roger S. Software engineering – a practitioner’s approach. 6 New York: 
McGraw Hill; 2007.