Processos de Desenvolvimento de Software

Prévia do material em texto

Primeiro, estudamos os diversos 
conceitos relativos a Software, 
Engenharia de Software, 
Processos, Modelos de 
Processos e Modelos Ágeis.
T
h
in
st
o
ck
/G
e
tt
y
 I
m
a
g
e
s
As preocupações com o prazo de desenvolvimento, o custo do
projeto e o atendimento ao usuário nem sempre adequado,
obrigou, principalmente aos desenvolvedores, a criação de
mecanismos que minimizassem estes problemas, inclusive com
a maior participação dos clientes e mudança de foco para a
qualidade do produto.
Troca-se a extensa documentação por artefatos mais simples,
rápidos e de fácil elaboração, para acompanhar e controlar o
cronograma de projetos em desenvolvimento. Os projetos
começam a iterar repetitivas vezes e a interação com os
usuários torna-se uma constante, já que se constata diversos
benefícios para a qualidade do produto.
O reaproveitamento de componentes de software, e os modelos de
processo de software incrementais e evolutivos, com o aparecimento
dos processos ágeis auxilia ainda mais na árdua e complexa atividade
de desenvolvimento de um produto de software, com os membros de
um projeto estabelecendo um vínculo maior entre si e compartilhando
crescimento técnico e profissional.
Depois de estudarmos os processos de 
software, conceituamos os modelos de 
referência da qualidade e o processo de 
qualidade de software. 
T
h
in
st
o
ck
/G
e
tt
y
 I
m
a
g
e
s
O uso de sistemas de informação nas empresas trouxe consigo uma
maior responsabilidade de se fazer softwares que atendessem aos
requisitos dos usuários, e com a qualidade por estes desejada.
Sustentada pelo avanço do interesse na qualidade de produtos, as
indústrias de software buscavam características que permitissem
indicar a qualidade de seus sistemas.
Os órgãos disciplinadores e avaliadores da 
qualidade e o surgimento das normas 
ISO/IEC também para a qualidade de 
software, permitiram que organizações e 
clientes tivessem uma visão mais clara e 
objetiva das características de qualidade de 
um software e de sua avaliação.Thins
to
ck
/G
e
tt
y
 I
m
a
g
e
s
As características e sub características para avaliar a qualidade de um
software trouxeram consigo a análise da experiência e da capacitação
das empresas que desenvolviam software e outro modelo de referência
da qualidade, CMM, passou a ser considerado tão ou mais importante
que a própria série ISO/IEC.
O modelo, modificado e atualizado, 
passa a considerar aspectos relativos 
a desenvolvimento, aquisição ou 
serviços. Então torna-se o CMM-I o 
modelo de referência mais cobiçado 
pelo mercado.
Na última unidade estudamos a 
qualidade de software e as 
métricas para sua avaliação.
T
h
in
st
o
ck
/G
e
tt
y
 I
m
a
g
e
s
As normas ISO/IEC e CMM-I se completam, cada qual na sua especificidade,
aplicação e objetivo. A qualidade de um software, garantida a partir da
qualidade de seu processo, e o foco da melhoria contínua determinado pelo
CMM-I, trouxeram a norma ISO/IEC 25000: 2005, que engloba as normas
ISO/IEC 9126 e 14598, e com esta, o modelo SQuaRE, que melhor
caracteriza as medições da qualidade de um software.
Por fim, facilitou-se a tarefa de analisar as características e a qualidade de
um software com a aplicação de diversas maneiras de se fazer as medições
da qualidade e o desafio de promover, manter, garantir e melhorar
continuamente a qualidade no processo de desenvolvimento, a partir do
projeto, e assegurando sua qualidade inclusive após sua implantação.
Finalizamos o 
estudo do tema: 
Engenharia de Software e 
Qualidade em Sistemas
Processos de Software
Responsável pelo Conteúdo:
Prof. Ms. Afonso Pavão
Revisão Textual:
Prof. Ms. Claudio Brites
5
Processos de Software
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução
• Orientações para Leitura Obrigatória
• Material Complementar Fonte: iStock/Getty Im
ages
 · Apresentar os conceitos de software e Engenharia de Software.
 · Compreender o que é o processo de software.
 · Entender o que é ciclo de vida de um de software.
 · Apresentar os modelos de processos de software.
Normalmente com a correria do dia a dia, não nos organizamos e deixamos para o último 
momento o acesso ao estudo, o que implicará o não aprofundamento no material trabalhado 
ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você poderá 
escolher um dia ao longo da semana ou um determinado horário todos ou alguns dias e 
determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões de 
materiais complementares, elementos didáticos que ampliarão sua interpretação e auxiliarão 
o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a veriicar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de troca 
de ideias e aprendizagem.
6
Unidade: Processos de Software
Introdução
Para podermos inserir a Engenharia de Software no contexto da Governança de Tecnologia 
de Informação, é importante que você compreenda que a atividade de desenvolvimento de 
sistemas em uma organização não se resume a escrever linhas de código fonte em uma 
linguagem de programação selecionada para aquela aplicação.
Um software (ou um sistema aplicativo) deve ser útil e funcional para seus usuários e ter a 
qualidade necessária para contribuir com a gestão de uma organização – e, claro, inclusive, 
para com a gestão da área de Tecnologia de Informação.
Por exemplo, algumas preocupações do gestor da TI estão relacionadas com o custo e 
o prazo de desenvolvimento de um sistema, se a qualidade desse sistema atenderá aos 
requisitos dos usuários, se esse software pode ser executado com as configurações 
atuais de hardware, de rede de computadores e infraestrutura computacional existentes.
Além disso, o gestor da TI ainda se preocupa com a qualificação e disponibilidade de 
sua equipe de desenvolvimento, obrigando-se a mantê-la permanentemente atualizada com as 
tecnologias mais recentes e emergentes e com a integração dos sistemas legados.
Outras preocupações do gestor estão relacionadas à segurança da organização, da 
informação e dos dados, da instalação e dos sistemas aplicativos, além de ter que garantir 
a continuidade dos negócios e o alinhamento da tecnologia da informação com os 
negócios e objetivos da empresa.
Para tanto, devido a essas variáveis internas à empresa – e sem falar das variáveis 
externas (política econômica, mercado no qual a empresa atua, com seus concorrentes, clientes 
e fornecedores) –, o gestor de TI deve fazer uso da Engenharia de Software para considerar 
e incrementar soluções para algumas dessas variáveis no processo de desenvolvimento de 
sistemas – onde possível, e conforme a aplicabilidade dos mesmos.
7
Orientações para Leitura Obrigatória
Nesta Unidade, ao abordarmos os conceitos gerais de software, de engenharia de 
software, de processos de software, do ciclo de vida e dos modelos de processos, é altamente 
recomendável a leitura dos capítulos e obras, e conforme orientações a seguir:
SOMMERVILLE, I. Engenharia de software. 8. ed. São 
Paulo: Pearson, 2011, a partir do login do aluno, clicando 
em “Serviços”, “Biblioteca” e em “E-books – Bib. Virtual 
Universitária”.
Cap. 1, 2, 4 e 17 – 
e-book disponível em: http://cruzeirodosulvirtual.com.br
Após carregar a página de capa do livro, observea seta à 
direita da tela para movimentar-se e ir à página seguinte ou 
retornar à anterior.
PRESSMAN, R. S. Engenharia de Software. 7.ed. Rio 
de Janeiro: Mcgraw-Hill do Brasil, 2011, a partir do login do 
aluno, clicando em “Serviços”, “Biblioteca” e em “E-books – 
Bib. Virtual Universitária”.
Cap. 1 a 3 – 
e-book disponível em: http://cruzeirodosulvirtual.com.br
Após carregar a página de capa do livro, observe a seta à 
direita da tela para movimentar-se e ir à página seguinte ou 
retornar à anterior.
Você também deve explorar e ler as obras identificadas no Material Complementar, sua 
proposta é ajudar você a compreender, sob ótica diferente do conteúdo desta Unidade, os 
assuntos abordados.
8
Unidade: Processos de Software
Material Complementar
Livros:
Sistemas de Informação Gerenciais – administrando a empresa digital
LAUDON, K.C. e LAUDON, J.P. 5. ed. São Paulo: Pearson/Prentice Hall, 2004.
Sistemas de Informação e as decisões gerenciais na era da internet
O’BRIEN, James A. 2. ed. São Paulo: Saraiva, 2004.
Engenharia de Software - Fundamentos, Métodos e Padrões
PÁDUA, W. 3. ed. São Paulo: LTC, 2009.
Engenharia de software – teoria e prática
PFLEEGER, S. L. 2. ed. São Paulo: Pearson/Prentice Hall, 2004.
9
Referências
LAUDON, K.C. e LAUDON, J.P. Sistemas de Informação Gerenciais – administrando a 
empresa digital. 5. ed. São Paulo: Pearson/Prentice Hall, 2004.
O’BRIEN, James A. Sistemas de Informação e as decisões gerenciais na era da internet. 
2. ed. São Paulo: Saraiva, 2004.
PFLEEGER, S. L. Engenharia de software – teoria e prática. 2. ed. São Paulo: Pearson/
Prentice Hall, 2004.
PRESSMAN, R. S. Engenharia de software. 7. ed. Rio de Janeiro: Mcgraw-Hill do 
Brasil, 2011.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2011.
10
Unidade: Processos de Software
Anotações
Cap I 
Fechamento da Unidade 
Com a última videoaula, concluímos nossa exposição sobre Engenharia de Software. 
Vamos relembrar alguns assuntos apresentados nesta Unidade. 
Primeiramente, estudamos os diversos conceitos relativos a softwares, Engenharia 
de Software, processos, modelos de processos e modelos ágeis. 
As preocupações com o prazo de desenvolvimento e o custo do projeto têm sido motivo de 
discussão entre clientes, engenheiros e estudiosos. Some-se a isso o atendimento nem 
sempre adequado ao usuário, o que faz surgir a proposta de diferentes paradigmas 
de softwares apoiados por métodos, critérios e ferramentas que tornem mais efetivo, barato e 
rápido o desenvolvimento de um sistema aplicativo. 
O foco dos modelos de software muda para o (bom) relacionamento com os usuários e, 
consequentemente, para a qualidade do produto. 
Com a evolução e expansão dos conceitos da garantia da qualidade, busca-se determinar 
pontos de controle durante o processo de desenvolvimento para avaliar se a qualidade até 
aquela etapa está adequada. 
Troca-se a extensa documentação por documentos mais simples, rápidos e de fácil 
elaboração, para acompanhar e controlar o cronograma dos projetos em desenvolvimento. 
Procura-se envolver cada vez mais os usuários no processo de desenvolvimento, de forma a 
reduzir os erros e as falhas de análise ou do projeto. 
Concomitantemente, os projetos começam a iterar repetidas vezes e a interação com os 
usuários passa a ser uma constante, pois é constatado seus benefícios para a qualidade do 
produto, fazendo com que o tempo para o desenvolvimento – e por conta disso também seu 
custo – sejam minimizados. 
A utilização e o reaproveitamento de componentes de software, tais como rotinas e funções, 
proporcionam uma aceleração na elaboração de protótipos incrementais e evolutivos que, além 
de atenderem mais rapidamente aos usuários, são testados com mais frequência – e de modo 
diferente daquele teste preparado pelos programadores. 
O aparecimento dos processos ágeis auxilia ainda mais na árdua e complexa atividade de 
desenvolvimento de um produto de software. Mais do que isso, ao deixar que a própria equipe 
monitore e controle seu planejamento e cronograma de forma integrativa, e também com os 
usuários, é possível estabelecer um vínculo maior entre os membros de um projeto. 
A elaboração dos códigos-fonte é dividida e, principalmente, compartilhada entre os 
programadores, surgindo assim a programação em pares. Sua grande vantagem 
(principalmente para efeitos de gestão de projetos) é que a troca de informações constantes e 
permanentes entre os membros possibilita que todos conheçam todas as partes do sistema, 
evitando que o conhecimento fique apenas com um profissional da equipe. 
Outro aspecto evolutivo da Engenharia de Software é o de que esse compartilhamento 
colabora com o crescimento técnico e profissional da própria equipe, já que nem todos os 
indivíduos possuem facilidade de comunicação escrita ou oral e/ou ainda o mesmo nível 
técnico de conhecimento. 
Dessa forma, esse compartilhamento de informações e o desenvolvimento colaborativo entre 
os membros facilita o treinamento, o acompanhamento, o gerenciamento e o controle dos 
projetos e das equipes pelo gestor da área de desenvolvimento. 
Lembre-se de estudar os materiais didáticos, a bibliografia recomendada e de fazer as 
atividades. 
Bem, com isso, encerramos esta Unidade. 
Nos vemos na próxima. 
Uma das maiores dificuldades do desenvolvimento de um sistema é compreender correta e 
adequadamente as necessidades do usuário. E para extrair as informações relativas 
aos requisitos, os engenheiros de software tem diversas dificuldades. 
Conforme Aurélio (Fonte: //dicionariodoaurelio.com/requisito), requisito é algo necessário e 
indispensável; condição indispensável; exigência;algo requerido. 
Após a coleta de dados realizada, os desenvolvedores ainda precisam identificar claramente os 
requisitos do sistema,e isso não é uma das tarefas mais fáceis. 
Primeiro, porque a própria indústria de Software não utiliza o termo requisito de uma forma 
consistente. Sommerville (2011) lembra que a compreensão do que é um requisito pode variar 
de uma declaração abstrata de uma função que o sistema deve disponibilizar ou de uma 
restrição do sistema, a uma, no outro extremo, declaração detalhada do sistema. Em 
segundo lugar, porque é difícil extrair corretamente as informações dos usuários, por mais que 
se utilize técnicas diferentes de coleta de dados. E em terceiro, porque os registros dos 
requisitossão feitos de uma forma desorganizada. 
O objetivo da Engenharia de Requisitos é elaborar por escrito a correta identificação do 
problema, fornecendo-a a todos os envolvidos com o sistema. Essa atividade inicia na fase 
de concepção do sistema, onde os analistas definem o escopo do projeto, e continua com o 
levantamento detalhado, refinando-se os requisitose modificando-os. A declaração dos 
requisitos pode prosseguir com a fase de modelagem. 
Conforme Pressman (2011), no Processo de Software, a Engenharia de Requisitos é uma ação 
da Engenharia de Softwareque começa na fase de Comunicação e se estende e continua na 
modelagem. A Engenharia de Requisitos deve se adequaràs necessidades do processo, do 
projeto, do produto e das pessoas que realizam o trabalho. 
A Engenharia de Requisitos disponibiliza um processo adequado para se conseguir entender 
as reais necessidades dos usuários, analisando-as e avaliando a viabilidade da solução, 
preparando uma que seja razoável, validando-a e gerenciando essas necessidades até que o 
sistema se torne operacional. 
De acordo com Pressman (2011), a Engenharia de Requisitos contempla sete fases: a 
concepção, o levantamento, a elaboração, a negociação, a especificação, a validação e a 
gestão. 
Requisitos são descrições dos serviços e de suas restrições que o software deverá fornecer. 
Esses devem ser bem declarados e compreensíveis, pois sãoessenciais para um adequado 
processo de desenvolvimento de sistemas. 
Há diversos tipos de requisitos, e cada um deles deve ser contemplado pelos analistas para 
efeitos de documentação e de implementação. 
O documento com os requisitos declarados podeter mais ou menos detalhes e formatações 
diferentes, mas todos devem conter as necessidades dos clientes. Nos links informados, você 
poderá verificar alguns exemplos de Software Requirements Specification – SRS. 
 
Com a última videoaula, concluímos nossa exposição sobre Engenharia de Requisitos. 
Vamos relembrar alguns assuntos apresentados nesta unidade: 
Estudamos aqui os diversos conceitos relativos à Engenharia de Requisitos, Requisitos 
de Software e Processos de Requisitos de Software, e suas considerações com os Modelos 
Ágeis. 
As preocupações com o prazo e o custo do desenvolvimento de projeto fazem surgir 
naturalmente técnicas para a especificação das necessidades dos usuários e, com isso, 
a Engenharia de Requisitos. 
A Engenharia de Requisitos inicia na fase de concepção do software, prosseguindo até a fase 
de modelagem, e deve se adequar às necessidades do projeto, produto e das pessoas 
envolvidas. 
Após o entendimento inicial, é necessário completar o levantamento de dados, o qual pode ser 
feito por intermédio de diversas técnicas. Essa etapa, além de crítica, é fundamental para 
que os requisitos dos usuários sejam bem compreendidos, pois, do contrário, fatalmente 
ocorrerão problemas durante ou após o projeto. 
É bom lembrarmos outro aspecto importante: que os requisitos dos usuários podem 
(normalmente o são) ser voláteis, pois a dinâmica da empresa irá gerar outras necessidades. 
As informações obtidas preliminarmente devem ser refinadas, para que o modelo 
do software contenha as funções requeridas. O documento que conterá as informações tem 
diversas nomenclaturas nas empresas, mas o importante é que tenha todas as informações 
necessárias. Elaborados os artefatos, esses devem ser revisados visando à sua 
qualidade para o projeto e sua implementação. 
Requisitos são funções que o software deverá executar (por isso devem ser consistentes, 
claros e completos, contendo as visões e os cenários de todos os tipos de usuário que dele 
farão uso), esses são os requisitos funcionais (de funcionalidade do software). 
Já os requisitos não funcionais, tratam das restrições de como aquelas funções serão 
disponibilizadas pelo software. Esses requisitos podem ser também requisitos de 
produto (relativos ao comportamento do software), organizacionais (têm sua origem nas 
políticas ou procedimentos da empresa) ou externos ao software (como processos de 
desenvolvimento, aspectos legais ou éticos). 
Os requisitos de um software podem ser também de domínio (são os especializados: podem 
ser algoritmos, novos requisitos funcionais ou novas restrições), de usuário (funções e suas 
restrições que o software deverá executar) ou de sistema(detalhes das funções e das 
restrições, devem descrever o comportamento do software e ser consistentes e completos – 
também são conhecidos como especificação funcional). 
Vale lembrar que o processo de engenharia de requisitos pode ser aplicado tanto 
em processos de software tradicionaisquanto nos modelos ágeis, sendo que nesses 
possibilitam aumento na performance. 
Com a abordagem iterativa e entregas incrementais dos modelos ágeis, além da 
colaboração entre os envolvidos, a definição dos requisitos em etapas auxilia o entendimento e 
a implementação do software. 
Nessa abordagem, pelas suas características, é inserida a função da qualidade, que irá 
maximizar a satisfação do cliente. Pode-se também elaborar diagramas de caso de uso 
(da UML) e seus respectivos casos de uso expandidos, para facilitar a compreensão 
do software. 
Uma boa engenharia de requisitos aplicada em um projeto é uma das garantias da qualidade 
de um software. 
Lembre-se de estudar os materiais didáticos, a bibliografia recomendada e de fazer as 
atividades. 
Bem, com isso encerramos esta unidade! 
Com a última videoaula concluímos nossa exposição sobre Qualidade de Software e modelos 
de referência. 
Vamos relembrar alguns assuntos apresentados nesta Unidade: 
Iniciamos nossos estudos com os conceitos relativos à qualidade e qualidade de software. 
Posteriormente, estudamos os modelos de referência e o processo de qualidade de software, 
concluindo com as métricas para a avaliação de sua qualidade. 
A disseminação e utilização dos sistemas de informação nas empresas trouxeram consigo, 
além das preocupações com o prazo e o custo de um projeto, a responsabilidade de se 
fazer softwares que atendessem aos requisitos dos usuários e com a qualidadepor esses 
desejada. 
A febre relativa à qualidade na década de 1980 ajudou a incentivar a indústria de software e 
seus clientes a buscarem características que possibilitassem indicar a qualidade de seus 
sistemas. 
A criação de órgãos disciplinadores e avaliadores da qualidade levou as empresas a também 
adotarem critérios para a análise de seus softwares antes de disponibilizá-los no mercado. 
O surgimento das normas ISO/IEC para a qualidade e, posteriormente, também para a 
qualidade de software permitiu que as organizações e clientes tivessem uma visão mais clara e 
objetiva das características de qualidade de um software e de sua avaliação. 
As diversas normas enunciadas e voltadas à qualidade de um software direcionaram usuários, 
clientes e desenvolvedoresa implementarem controles que pudessem salvaguardar as 
características e as subcaracterísticas definidas daquela norma para a qualidade. 
À medida que mais e mais sistemas eram desenvolvidos, a experiência e a capacitação das 
empresas que desenvolviam software logo eram referenciadas como exemplo de qualidade a 
ser seguida. 
Entretanto, os clientes tornam-se mais exigentes e cada vez mais conhecedores do que os 
sistemas podiam fazer por eles, por sua gestão e por sua empresa. 
Os algoritmos e as métricas para a avaliação da qualidade foram cruciais também para a 
determinação do que é e quais são os requisitos para a qualidade dessas mesmas métricas, a 
fim de atingirem seu objetivo, já que os parâmetros para a avaliação e seu processo avaliativo 
também devem ter qualidade assegurada. 
Surgem outros modelos de referência da qualidade, como o CMM, e seu direcionamento à 
capacitação das empresas desenvolvedoras de solução, o qual provocou uma reviravolta 
nas softwarehouses, com os clientes considerando-o tão ou mais importante que a própria 
série ISO/IEC. 
Esse modelo de maturidade e capacitação logo é modificado e atualizado, passando a contar 
com aspectos relativos a desenvolvimento, à aquisição ou aos serviços. O CMM-I torna-se o 
modelo de referência mais cobiçado pelo mercado, tendo sido considerado, nos níveis mais 
elevados, condição para a comercialização de softwares. 
Entretanto, as normas ISO/IEC e CMM-I se completam, cada uma na sua especificidade, 
aplicação e objetivo. As ponderações sobre qualidade do software, garantida a partir da 
qualidade do processo, e o foco da melhoria contínua determinado pelo CMM-I, trouxeram 
novas possibilidades ao mercado consumidor, atento às modificações e exigências cada vez 
maiores. 
Com essas circunstâncias, surgem questionamentos sobre como seria possível avaliar 
adequadamente os softwares, já que a qualidade é considerada por muitos como subjetiva. 
Obviamente, a evolução trouxe com ela a norma ISO/IEC 25000: 2005, que engloba as normas 
ISO/IEC 9126 e 14598, ainda em uso, e, com essa, o modelo SQuaRE, que melhor caracteriza 
as medições da qualidade de um software. 
Aos usuários, ficou facilitada a árdua tarefa de analisar as características e respectivas 
qualidades do software pretendido; aos desenvolvedores, o desafio de promover, manter, 
garantir e melhorar continuamente aqualidade no desenvolvimento de seus softwares, a partir 
do projeto, e assegurando-a inclusive pós-implantação. 
Lembre-se de estudar os materiais didáticos, a bibliografia recomendada e de fazer as 
atividades. 
Bem, com isso encerramos essa unidade !!! 
Nos vemos na próxima. 
 
 
Engenharia de Software e 
Qualidade em Sistemas
Qualidade de Software e Modelos de Referência
Responsável pelo Conteúdo:
Prof. Ms. Afonso Pavão
Revisão Textual:
Prof. Ms. Claudio Brites
5
Qualidade de Software e Modelos de Referência
Nesta unidade, trabalharemos os seguintes tópicos:
• Introdução
• Orientação para Leitura Obrigatória
• Material Complementar Fonte: iStock/Getty Im
ages
 · Apresentar os conceitos de Qualidade de Software.
 · Compreender o que são métricas de Software.
 · Entender a abrangência e importância dos testes de Software.
 · Apresentar os modelos de referência para a qualidade de Software.
Normalmente com a correria do dia a dia, não nos organizamos e deixamos para o último 
momento o acesso ao estudo, o que implicará o não aprofundamento no material trabalhado 
ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você poderá 
escolher um dia ao longo da semana ou um determinado horário todos ou alguns dias e 
determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões de 
materiais complementares, elementos didáticos que ampliarão sua interpretação e auxiliarão 
o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a veriicar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de troca 
de ideias e aprendizagem.
6
Unidade: Qualidade de Software e Modelos de Referência
Introdução ao Tema
Quando falamos sobre qualidade de software é necessário lembrar que o processo de 
software é extenso e complexo.
A engenharia de requisitos ainda é um dos “calcanhares de Aquiles” do desenvolvimento 
de sistemas.
O termo qualidade ganhou notoriedade com a busca pela qualidade de produtos na década 
de 1980 e expandiu-se rapidamente ao longo dos anos 1990.
Qualidade de um produto se refere ao atendimento às suas especificações técnicas – 
seus “requisitos”.
Com o avanço da tecnologia e a constante inovação dos produtos, as empresas começaram 
a busca pela certificação da International Standardization for Organization – ISO, tornando-
se essa uma condição essencial para comercializar seus produtos no mercado mundial.
Com o software sucedeu o mesmo, consequência da expansão do interesse na automatização 
de processos, principalmente por parte das médias e pequenas empresas.
Os clientes de software houses também começaram a exigir para o software cada vez 
mais o atendimento de suas necessidades, e com maior qualidade. 
Os consumidores viram então as empresas buscando sua certificação com total 
prioridade. Proliferam-se as organizações que necessitavam mapear seus processos para 
obter alguma certificação.
As empresas que tinham seus processos mapeados saíram na frente e passaram a usar 
a certificação como propaganda para alavancar suas vendas, veicular seus produtos e sua 
imagem de seriedade.
Logo a certificação passou a ser considerada imprescindível também para as empresas do 
produto software, pois seriam vistas inclusive como organizações sérias, confiáveis e seguras.
Assim, o software também passou a ter as suas especificações técnicas, a exemplo de 
outros produtos desenvolvidos pela engenharia de produtos.
As especificações técnicas do software ficaram conhecidas como requisitos do software, 
e deveriam atender às necessidades dos clientes.
Os processos de software e suas atividades contribuíram para a melhoria desses produtos, 
uma vez que a atenção dos profissionais da tecnologia da informação ficou voltada para que 
cada etapa do desenvolvimento também tivesse a qualidade adequada.
A transição de controle de qualidade para garantia de qualidade mudou radicalmente a visão 
dos consumidores e dos fabricantes – independente do produto fabricado.
A visão de que o produto final deveria ter qualidade evoluiu para assegurar que o 
produto final tivesse a qualidade requerida, e isso somente seria possível com adequados 
controles em cada etapa do processo de fabricação.
7
E com o software não foi diferente, a engenharia de requisitos impulsionou e contribuiu 
para que sua qualidade melhorasse.
A adoção de normas mais rígidas de processos de software para o desenvolvimento de 
sistemas, a iteratividade e a interação crescente com os clientes sempre mais exigentes fez 
surgir as normas gerais para o desenvolvimento de sistemas.
Com diversas sugestões, o detalhamento dessas normas procurou tornar padrão os requisitos 
da qualidade do produto software.
Mas, com isso, foi necessário criar mecanismos adequados para avaliar as características 
da qualidade de um software. E como sua complexidade diverge conforme a organização e as 
necessidades de controle que cada usuário tem, foram criadas diversas métricas para realizar 
essa medição.
As empresas de maior porte e software houses tradicionais – e, portanto, com maior 
experiência no desenvolvimento de sistemas – já possuíam seu histórico e, consequentemente, 
tinham um bom diagnóstico da qualidade de seus produtos. Existiam, contudo, diversas 
empresas produzindo sistemas, e cada uma delas em diferentes estágios de maturidade de 
desenvolvimento de software.
O advento dos critérios para identificar a capacitação da arquitetura de desenvolvimento, 
elaborados pelo Software Engineering Institute – SEI, da Universidade de Carnegie Mellon 
– o Capability Maturity Model for Software – CMM e o Integrated – CMM-I possibilitaram, 
juntamente com outros critérios, elaborar um modelo para a avaliação do nível da 
experiência dos profissionais e das organizações na elaboração de um software.
Esse modelo então passou a ser a nova referência e o passaporte para a comercialização 
de softwares devido à sua respeitabilidade e amplitude de aceitação. Assim, as empresas 
se tornam igualmente respeitáveis e confiáveis ao se prepararem para serem submetidas à 
avaliação oficial do SEI.
8
Unidade: Qualidade de Software e Modelos de Referência
Orientação para Leitura Obrigatória
Nesta Unidade, ao apresentarmos os conceitos gerais de qualidade de software, de métricas 
e testes, e de modelos de referência para a qualidade de software, é recomendável a leitura 
dos capítulos e obras, conforme orientações a seguir:
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: 
Pearson, 2011. Cap. 22, a partir do login do aluno, clicando em 
“Serviços”, “Biblioteca” e em “E-books – Bib. Virtual Universitária”.
Após carregar a página de capa do livro, observe a seta à direita 
da tela para movimentar-se e ir à página seguinte ou retornar 
à anterior.
PRESSMAN, R. S. Engenharia de Software. 7.ed. Rio de 
Janeiro: Mcgraw-Hill do Brasil, 2011. Cap. 14, 16, 17, 23 e 30, 
a partir do login do aluno, clicando em “Serviços”, “Biblioteca” e 
em “E-books – Bib. Virtual Universitária”.
Após carregar a página de capa do livro, observe a seta à direita 
da tela para movimentar-se e ir à página seguinte ou retornar 
à anterior.
Você também deve explorar e ler o material identificado no Material Complementar, pois 
sua proposta é ajudá-lo a compreender, sob ótica diferente desta unidade de conteúdo, os 
assuntos abordados.
9
Material Complementar
Sites:
Associação Brasileira de Normas Técnicas – ABNT para aquisição.
Disponível em: https://goo.gl/S191uo, acesso em 12/04/2016.
Wikipedia– ISO/IEC 9126.
Disponível em: https://goo.gl/Whbkgw, acesso em 12/04/2016.
Leituras:
PEPP: Processo de Software para Empresas de Pequeno Porte Baseado no 
Modelo CMMI
Artigo publicado e premiado no SBQS de 2005, na categoria excelência.
Disponível em: http://goo.gl/1Dn9Qu, acesso em 15/3/2016.
Quality Attributes
Atributos da qualidade de software.
Disponível em: http://goo.gl/aVmzoK, acesso em 12/04/2016.
10
Unidade: Qualidade de Software e Modelos de Referência
Referências
BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Elsevier, 2002.
COUTO, Ana B. CMMI - integração dos modelos de capacitação e maturidade de sistemas. 
Rio de Janeiro: Ciência Moderna, 2007.
KOSCIANSKI, André & SOARES, Michel dos Santos. Qualidade de Software. 2. ed. São 
Paulo, Novatec: 2007.
PÁDUA, W. Engenharia de Software - Fundamentos, Métodos e Padrões. 3. ed. São 
Paulo: LTC, 2009.
PRESSMAN, R. S. Engenharia de Software. 7. ed. Rio de Janeiro: Mcgraw-Hill do 
Brasil, 2011.
SOMMERVILLE, I. Engenharia de software. 8. ed. São Paulo: Pearson, 2011.
11
Anotações