Engenharia de Software – Seus princípios e propósito

André F. Gallo, Flávio A. Gomes, Nelson B. Luiz, Wagner Cunha

Pós-graduação em Engenharia de Projetos de Software

Universidade do Sul de Santa Catarina
Campus da Grande Florianópolis - Palhoça - SC
{andre,nelson,flavio}@fln.politec.com.br, wcunha@seventh.com.br

Abstract. The software engineering was born with the proposal to organize the
software’s development area, that until 1990, was met in an immature period,
without practical boarding for the resolution of problems commonly found
inside the companies that develops software: blown up stated periods,
expensive costs with the maintenance of software, low quality and unsatisfied
users. This article presents the software´s engineering to the reader,
approaching its knowledge´s areas, and illustrating a possible solution for the
pointed problems.

Resumo. A engenharia de software nasceu com a proposta de organizar a

área de desenvolvimento de software, que até meados de 1990, encontrava-se
em um estágio imaturo, sem abordagens práticas para a resolução de
problemas comumente encontrados dentro das empresas que desenvolvem
software: prazos estourados, gastos exorbitantes com a manutenção do
software, baixa qualidade e o principal, usuários insatisfeitos. Este artigo
apresenta a engenharia de software ao leitor, abordando suas principais
práticas e áreas de conhecimento, ilustrando uma possível solução para os
problemas apontados.

1. Introdução
Atualmente, as empresas produtoras de software têm perseguido um objetivo em
comum: produzir software com alto nível de qualidade. Segundo Cortês e Chiossi
[COR01], “a preocupação com a qualidade deixou de ser um diferencial competitivo e
passou a ser um pré-requisito básico para participação ativa no mercado”. É exatamente
neste contexto, que a engenharia de software tem ganhado espaço dentro das
organizações, contribuindo com métodos, ferramentas e metodologias avançadas para a
obtenção de tal nível de qualidade. O IEEE Computer Society [SWE04] define a
engenharia de software como: “A aplicação de uma metodologia sistemática,
disciplinada e quantificável para o desenvolvimento, a operação e a manutenção do
software”.
Este artigo tem como principal objetivo apresentar ao leitor os fundamentos da
engenharia de software, descrevendo suas áreas de conhecimento, para que ao final, o
leitor consiga assimilar a necessidade de utilizar o conjunto de práticas engenharia de
software em seus projetos de software.
2. Áreas de conhecimento da engenharia de software
O IEEE Computer Society, através do guia do conjunto de conhecimentos da engenharia
de software [SWE04], define que a engenharia de software possui dez áreas de
conhecimento e seis disciplinas relacionadas, conforme ilustrado nas figuras abaixo:

Figura 1. As primeiras cinco áreas de conhecimento.

 Figura 2. As cinco últimas áreas de conhecimento e as oito disciplinas
relacionadas.

2.1. Requisitos de software

A engenharia de requisitos ajuda os engenheiros de software a compreender melhor os
problemas relacionados ao levantamento e ao gerenciamento das informações fornecidas
pelos usuários de software. Isto inclui um conjunto de tarefas que levam a um
entendimento melhor de qual será o impacto do software sobre o negócio, do que o
cliente quer e de como os usuários finais vão interagir com o software [PRE06].
A engenharia de requisitos está subdivida em 4 áreas, a saber: elicitação, análise,
especificação e validação dos requisitos de software [SWE04]. Nesse modelo, cada uma
das atividades desenvolvidas podem ser resumidas na seguinte tabela:
Tabela 1. Subáreas da engenharia de requisitos.

Elicitação Consiste na identificação dos requisitos a partir de consulta aos

stakeholders, da análise de documentos, da análise de informações
do domínio e/ou de estudos de mercado.
Análise e Consiste na análise detalhada dos requisitos com a negociação entre
Negociação os diferentes stakeholders visando decidir quais os requisitos que
serão aceitos.
Especificação Os requisitos aprovados na atividade de análise e negociação devem
ser registrados em um documento apropriado, em nível de
 detalhamento adequado.
Validação Após a especificação e documentação, os requisitos devem sofrer
cuidadosa verificação de consistência e completitude.
Um requisito de software é uma descrição dos principais recursos de um produto
de software, seu fluxo de informações, comportamentos e atributos, fornecendo uma
estrutura básica para o desenvolvimento de um produto de software. O grau de
compreensibilidade, precisão e rigor da descrição fornecida por um documento de
requisitos de software tende a ser diferente proporcionalmente ao grau de qualidade do
produto resultante [PET01].
Sob essa perspectiva, teríamos duas categorias de requisitos: aqueles
responsáveis pela funcionalidade do sistema e aqueles responsáveis por qualidades que
devam estar presentes, tais como desempenho, integridade, disponibilidade e segurança.
Os primeiros são denominados requisitos funcionais e os últimos requisitos não
funcionais [NAD02].
Os requisitos possuem uma natureza volátil. Diversos fatores contribuem para
sua instabilidade ao longo do tempo: mudanças externas no ambiente (mudanças de
legislação, mudanças no mercado, mudança no posicionamento estratégico da empresa),
erros incorridos no processo de requisitos, entre outros. Todos esses fatores fazem com
que seja necessário alterar os requisitos. Tais alterações precisam ser conduzidas de
forma ordenada para que não se perca controle sobre o prazo e o custo do
desenvolvimento. A atividade de administrar os requisitos ao longo do tempo é
denominada de gerenciamento de requisitos [NAD01].
No centro da atividade de gerenciamento de requisitos está a rastreabilidade. A
rastreabilidade pode ser definida como a habilidade de se acompanhar a vida de um
requisito em ambas as direções do processo de software e durante todo o seu ciclo de
vida. Esta tarefa é importante, pois permite avaliar o impacto quando ocorrer uma
mudança. Para auxiliar nessa atividade, a indústria de software começou a desenvolver
ferramentas para gerenciar requisitos [NAD01].
No contexto da engenharia de requisitos, uma área de extrema relevância ao
desenvolvimento de software de forma geral, há a necessidade de introduzir o processo
de gerenciamento de requisitos, permitindo o acompanhamento, a evolução, a detecção
e correção de problemas de forma sistêmica, garantindo a qualidade dos artefatos
gerados para as próximas fases.

2.2. Design de software

O design ou projeto de software começa quando a primeira iteração da engenharia de
requisitos é concluída. O objetivo do projeto de software é aplicar um conjunto de
princípios, conceitos e práticas que levam ao desenvolvimento de um sistema ou
produto de alta qualidade [PRE06].
O design de software vai de uma visão global do software a uma visão mais
concentrada que define o detalhe necessário para implementar o sistema. O processo
começa enfocando a arquitetura, no qual subsistemas são definidos, mecanismos de
comunicação entre sistemas são estabelecidos, componentes são identificados e uma
descrição detalhada sobre cada componente é desenvolvida. Adicionalmente interfaces
internas e externas com o usuário são projetadas [PRES06].
Além da arquitetura propriamente dita, ao longo dos anos, foram criadas
soluções altamente eficazes para resolver problemas comuns, encontrados na maioria
dos softwares ou em determinadas áreas de conhecimento.
Durante todo o processo de design, um engenheiro de software deve procurar
toda oportunidade de reutilizar padrões de projeto existentes (quando eles satisfazem às
necessidades do projeto) em vez de criar outros [PRES06].

2.3. Construção de software

Esta área de conhecimento da engenharia de software trata dos conceitos relacionados à
criação de software executável, os quais incluem a codificação, verificação, testes de
unidade e de integração, e depuração. Possui ligações com todas as demais áreas de
conhecimento, mas principalmente com as áreas de design e testes, pois muito do
processo de construção de software trata de atividades relacionadas a essas áreas
[SWE04].
Dependendo do ciclo de vida e modelo de desenvolvimento adotado, as
atividades desta fase podem ser combinadas com atividades de design e testes, e em
alguns casos essa combinação é tratada como uma atividade da fase de construção.
Entretanto, as atividades de construção de software estão no centro do processo
de desenvolvimento, e dependendo do tamanho do projeto e modelo de ciclo de vida
adotado, utilizam entre 30 e 80 por cento do tempo total do desenvolvimento, e são
responsáveis por 50 a 75 por cento dos erros totais [MCC04], fatores que demonstram a
necessidade de estudo de melhores práticas nessa área.
Esse estudo deve incluir os princípios fundamentais da construção de software:
redução de complexidade, antecipação de mudanças, estruturação para verificação e uso
de padrões, além das atividades de gerenciamento da construção e das considerações
práticas pertinentes à área, visto que a área de conhecimento de construção é a que está
mais ligada a atividades práticas [SWE04].
A redução de complexidade é alcançada através da utilização de padrões e
normas de construção e da criação de código simples e legível. Kerninghan [KER99]
considera esta simplicidade e clareza são a base para a construção de software inteligível
e gerenciável, que combinados à estruturação para verificação permitem revisões de
código e facilitam os testes, além de apoiar a antecipação de mudanças.
O gerenciamento da construção está relacionado ao modelo e ao método de
desenvolvimento escolhido, os quais influenciam a habilidade do projeto de contemplar
esses princípios fundamentais da construção. As atividades de gerenciamento, como as
métricas, por exemplo, estão ligadas a área de conhecimento da engenharia de processo.
As considerações práticas relacionadas à área de construção incluem as
atividades de design durante a construção, as linguagens de construção empregadas, a
codificação, os testes de unidade e de integração, a reutilização de código, a qualidade
de construção, e a integração dos componentes de software.
2.4. Teste de software
A área de conhecimento de testes de software compreende as atividades desenvolvidas
para a avaliação da qualidade do software, através da identificação de defeitos e
problemas. Essa verificação compreende a execução de um conjunto finito de casos de
teste, adequadamente retirados de um domínio geralmente infinito de possibilidades, e a
sua comparação com os resultados esperados [SWE04].
Essa definição inclui os princípios fundamentais da atividade de teste: a
execução de testes, para diferenciá-la das atividades de análise estática do código; o
conjunto finito de testes, pois são raros os softwares onde é possível um teste exaustivo
de todas as possibilidades; a seleção adequada dos casos de testes, que está relacionada à
técnica e aos critérios de teste escolhidos; e por fim a comparação com os resultados, o
que implica na especificação dos critérios de aceitação dos testes [GUS02].
A área de testes de software está ligada diretamente às áreas de conhecimento de
construção, manutenção e qualidade de software. É importante ressaltar que
diferentemente da área de qualidade de software, a área de testes é focada apenas nos
testes dinâmicos, ou seja, os que compreendem execução de código.
As atividades de testes devem englobar todo o processo de desenvolvimento e
manutenção, inclusive com a elaboração dos planos e procedimentos de testes já nas
primeiras fases do processo de requisitos, e com o refinamento dos mesmos durante a
evolução do desenvolvimento [SWE04].
Além disso, as atividades de testes devem ser executadas em diferentes níveis de
igual importância, que são os testes de unidade, testes de integração e testes do sistema.
Para cada nível, os testes devem ser conduzidos sob a visão de objetivos específicos,
como, por exemplo, os testes de aceitação de acordo com os requisitos, testes de
instalação, testes de conformidade com a especificação, testes de desempenho, entre
outros.
As técnicas de testes de software são classificadas em black-box - que são os
testes que levam em consideração apenas a verificação de entradas e saídas, sem acesso
as estruturas internas do software; e white-box – testes baseados no design e no código
do software; e a combinação de elementos de ambas as técnicas deve ser base para uma
estratégia de testes razoável [MYE04].

2.5. Manutenção de software

Mesmo após a conclusão de uma campanha de testes eficiente, o software desenvolvido
ainda pode conter falhas. Além disso, o ambiente de operação de um software muda
com o decorrer do tempo, e o software precisa acompanhar essas mudanças. Dessa
forma, a área de manutenção de software compreende as atividades necessárias para
fornecer suporte a software de maneira eficiente e viável, e por sua abrangência está
ligada a todas as demais áreas de conhecimento da engenharia de software [SWE04].
Essa necessidade de adaptação e evolução contínua é inerente ao software, visto
que com o decorrer do tempo surgem diferenças entre o software e o seu ambiente
operacional, e essa evolução deve ocorrer através de um processo controlado de
feedback e manutenção, caso contrário o grau de satisfação com o software em execução
irá decair com o tempo [LEH96].
 A manutenção de softwares existentes é responsável por mais de 60 por cento do
esforço empregado por uma organização de desenvolvimento, e este valor tende a
aumentar conforme mais softwares são produzidos [PRE06].
As atividades de manutenção incluem as realizadas antes da entrega do software,
como o planejamento de manutenção, ou pós-entrega, como a correção de falhas ou
desenvolvimento de melhorias. De acordo com Pressman [PRE06] são divididas em
quatro categorias: manutenção corretiva, manutenção adaptativa, manutenção perfectiva,
e manutenção preventiva.
Os pontos chaves da manutenção de software se referem às técnicas de
compreensão do software a ser modificado e reengenharia e engenharia reversa de
software, os testes para garantir que as modificações não geraram efeitos colaterais, a
análise de impacto das alterações solicitadas, e a promoção da manutenibilidade do
software. Além disso, alguns pontos devem ser considerados no aspecto gerencial, como
o alinhamento com os objetivos da organização, a definição do processo de manutenção,
e até mesmo o outsourcing desta atividade [SWE04].
O processo de manutenção é definido por etapas semelhantes ao processo de
desenvolvimento, como a análise, projeto, codificação, testes e documentação, e por
atividades que são únicas ao processo de manutenção, como a análise de impacto de
alterações, a revisão e aceitação de modificações, as atividades de suporte do software, e
o planejamento de manutenção de um software.
Outro elemento crítico da manutenção de software é o processo de gerência de
configuração, que difere da gerência de configuração do desenvolvimento pela
quantidade de pequenas alterações que precisa ser controlada em um software
operacional. Além disso, um processo de controle de qualidade de software precisa ser
definido e aplicado para dar suporte a atividade de manutenção.

2.6. Gerenciamento da configuração de software

Uma disciplina da engenharia de software que vem ganhando crescente destaque em
projetos de software é a gerência de configuração do software, ou software
configuration management – SCM. A razão para tanto destaque é muito simples: se
entendermos todo o processo de desenvolvimento de software como um software, a
SCM pode ser vista como o subsistema de entrada e saída deste software.
Assim, o gerenciamento de configuração, mais comumente chamado de gestão
de configuração de software, é o desenvolvimento e a aplicação de padrões e
procedimentos para gerenciar um produto de sistema em desenvolvimento. Esse
gerenciamento é necessário porque na medida em que ele se desenvolve são criadas
versões diferentes de software que incorporam propostas de mudanças, correções de
defeitos e adaptações. É possível que haja várias versões em desenvolvimento e em uso
ao mesmo tempo, sendo necessário manter o controle das mudanças que foram
implementadas e de como essas mudanças foram incluídas no software.
Segundo Pressman [PRE06], a saída do processo de software é a informação,
que pode ser dividida em três categorias: programas de computador, produtos de
trabalho e dados. Os itens que compreendem toda a informação produzida como parte
do processo de software são chamados coletivamente de configuração de software.
 A primeira lei da engenharia de software (Pressman, R., 2006, apud Berlack, H.
R., 1992) diz: “Independentemente de onde você está no ciclo de vida do sistema, o
sistema vai se modificar e o desejo de modificá-lo vai persistir ao logo do ciclo de
vida”. Esta modificação pode ocorrer em qualquer época por qualquer motivo.
Os processos relacionados à SCM possuem basicamente as seguintes atividades:
implementação do processo, identificação da configuração, controle da configuração,
relato da situação, avaliação da configuração, e gerência de liberação de entrega
[SWE04].
O sucesso do projeto de software está muitas vezes associado com a adoção de
processos de software como o de SCM. Porém, a adoção desses processos é uma tarefa
complexa que muitas vezes acaba por inviabilizar as empresas em sair do diagnóstico,
onde se observa a necessidade em implantar o processo, para chegar ao operacional,
onde se tem a execução destes processos nos projetos de software.
Isto se deve muitas vezes ao fato de se acreditar que a implantação de processos
de software em uma empresa de software, como o caso da implantação do processo de
SCM, ocorre simplesmente pela adoção de ferramentas. No entanto, a maior parte dos
custos envolvidos nesta implantação relaciona-se a gastos com recursos humanos e na
estruturação organizacional.
O processo de SCM apóia os demais processos de desenvolvimento de software
e está relacionado a diversas atividades realizadas durante o desenvolvimento de um
projeto de software. Portanto, implantá-lo implica em afetar vários setores da
organização. Além disso, os processos de SCM, no período de implantação, podem
acarretar uma maior lentidão do processo de desenvolvimento de software, incorporando
práticas muitas vezes vistas como burocráticas.

2.7. Gerenciamento da engenharia de software

O gerenciamento da engenharia de software pode ser definido como a aplicação do
gerenciamento das atividades, do planejamento, da coordenação, da mensuração, do
monitoramento, do controle e do nível de reportagem, para assegurar que o
desenvolvimento e a manutenção do software é sistemática, disciplinada e qualificada
[SWE04].
O processo de desenvolvimento de software é complexo e abrangente. Com o
objetivo de garantir que este processo seja executado de forma correta, é preciso
gerenciar a própria engenharia de software.
Este gerenciamento é realizado através da aplicação e da integração dos
seguintes processos de gerenciamento de projetos: iniciação, planejamento, execução,
monitoramento e controle, e encerramento [PMB04].
Cada processo tem sua importância dentro do projeto, sendo este da natureza de
software ou de qualquer outra, porém, outro fator de suma importância é a das pessoas
que fazem parte do projeto. Sem uma equipe bem motivada e gerenciada, os processos
necessários para controlar e gerenciar a engenharia de software não serão aplicados com
eficácia.
2.8. Processo de engenharia de software
No desenvolvimento de software, existe uma seqüência de atividades que produzem
uma variedade de documentos e um programa executável, que compreende um
conhecimento aplicado. Estas atividades da engenharia são conhecidas por processo de
software.
O processo de engenharia de software é subdividido em 4 áreas: Implementação
e mudança do processo, definição do processo, verificação do processo e mensuração do
processo e do produto [SWE04].
A definição do processo é uma fase importante, onde é verificado qual modelo
de processo ou ciclo de vida de software será adotado. Atualmente, inúmeros modelos
de ciclo de vida de software são utilizados e os mais comuns são: modelo de clico de
vida clássico, modelo espiral, modelo incremental, modelo de prototipação e modelo
espiral para círculo.
Como exemplo, a figura abaixo traz a ilustração do modelo de vida clássico,
também conhecido como modelo em cascata. Este modelo é o paradigma mais antigo da
engenharia de software, por sugerir uma abordagem sistemática e seqüencial para o
desenvolvimento de softwares.

Figura 3. Modelo de ciclo de vida clássico ou em cascata.

Para Fowler & Scott, não existe um único processo para o desenvolvimento de
software. Vários fatores associados com o desenvolvimento de software levam a vários
tipos de processos. As equipes devem criar seus próprios processos, utilizando
processos publicados como orientação e não como padrões a serem seguidos (Fowler &
Scott, 2000 p.30).
Portanto, o não existe um processo ou ciclo de vida que possa ser eleito como o
melhor. Existe o modelo de ciclo de vida que melhor se adequará ao desenvolvimento
de determinado software, levando em consideração as características do projeto, como
equipes disponíveis, ferramentas a serem utilizadas, aplicação de padrões existentes,
infra-estrutura e etc.

2.9. Ferramentas e métodos da engenharia de software

O acrônimo CASE, computer-aided software engineering (engenharia de software com
auxílio de computador) se refere a uma gama de diferentes tipos de programas utilizados
para apoiar as atividades do processo de software, como a análise de requisitos,
modelagem de sistema, a depuração e os testes. Todos os métodos atualmente são
fornecidos com tecnologia CASE associadas, como no caso de editores para anotações
utilizadas no método, módulos de análise que verificam o modelo do sistema de acordo
com as regras de negócios e geradores de relatórios para ajudar na criação do sistema
[SOM03].
A engenharia de software abrange um conjunto de três elementos fundamentais -
métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do
processo de desenvolvimento do software e oferece ao profissional uma base para a
construção de software de alta qualidade e produtivamente. As ferramentas de
engenharia de software proporcionam apoio automatizado ou semi-automatizado aos
métodos, sendo denominadas de ferramentas CASE.
As ferramentas CASE podem ser classificadas por função, por seus papéis como
instrumentos para os gerentes e para o pessoal técnico, pelo uso que elas têm nas várias
etapas do processo de engenharia de software, pela arquitetura do ambiente (hardware
ou software) que as suporta ou até mesmo pela origem ou custo [PRE06]. A seguir é
apresentada uma taxonomia, que usa a função como critério primordial: ferramentas de
planejamento de sistemas comerciais; ferramentas de gerenciamento de projetos;
ferramentas de análise e projeto; ferramentas de programação; ferramentas de
prototipação; ferramentas de manutenção; ferramentas de integração e testes;
ferramentas de estrutura; e suporte [PRE06].
Os tipos de ferramentas são [PRE06]: ferramentas de planejamento, ferramentas
de edição, ferramentas de gerência de mudanças, ferramentas de gerências de
configuração, ferramentas de prototipação, ferramentas de apoio a métodos, ferramentas
de processadores de linguagem, ferramentas de análise de programas, ferramentas de
testes, ferramentas depuração, ferramentas de documentação e ferramentas de
reengenharia.
As ferramentas de engenharia de software auxiliadas por computadores
envolvem cada etapa do processo de engenharia de software e aquelas atividades de
“guarda-chuva” que são aplicadas no decorrer de todo processo. A ferramenta CASE
compreende um conjunto de blocos de construções que se inicia em um nível de
hardware e software de sistema operacional e termina em ferramentas individuais
[PRE06].

2.10. Qualidade de software

A gestão da qualidade de software talvez seja o tema mais discutido dentro do mundo de
informática atual. Isso se dá, em grande parte, pela falta de adoção de uma boa política
de qualidade e de uma metodologia que garanta a qualidade do software dentro das
empresas. As empresas produtoras de software querem que seus produtos tenham
qualidade, mas poucas conseguem obter um nível razoável.
Existem diversas definições para qualidade. Para Crosby, qualidade significa “a
conformidade dos requisitos do usuário” (SWEBOK, 2004, apud Crosby P., 1979). Já
para Humphrey, qualidade significa “atingir níveis excelentes de aptidão para o uso do
software”. (SWEBOK, 2004, apud Humphrey W., 1989). Uma definição mais
abrangente e atual foi dada pela norma ISO9001-2000, onde qualidade é definida como
“o grau em que um conjunto de características inerentes cumprem suas exigências.”
Um erro comumente encontrado dentro das organizações é o fato da qualidade
ser introduzida apenas na fase final do processo de desenvolvimento, onde o software já
se encontra codificado. Nesta fase, o custo para corrigir algum problema detectado é
extremamente alto, muitas vezes inviabilizando a implementação das correções
necessárias.
Com o intuito de evitar este cenário, as empresas produtoras de software estão
adotando metodologias que garantam a qualidade em todo o processo de
desenvolvimento de software. Abaixo, uma lista identifica as principais metodologias,
padrões e normas que utilizadas:
a) Norma ISO 9001:2000. Descreve os elementos de garantia de
qualidade em termos genéricos, que podem ser aplicados a qualquer
negócio independentemente dos produtos ou serviços oferecidos.
b) Modelo de melhoria do processo de software Brasileiro (MPS.BR).
Modelo baseado no CMMI (Capability Maturity Model Integrated),
nas normas ISSO/IEC 12207 e ISO/IEC 15504, que define um
processo para melhoria da qualidade de software voltado para a
realidade das empresas de desenvolvimento brasileiras.
c) CMMI (Capability Maturity Model Integrated). Modelo amplamente
reconhecido e utilizado nas empresas de desenvolvimento de software.
Tem como principal objetivo, melhor a capabilidade dos processos, ou
seja, garantir que um processo tenha habilidade para alcançar seu
resultado esperado.

3. Conclusão
Os softwares e sistemas computacionais afetam profundamente o desenvolvimento
econômico das nações. A aplicação dos conceitos de engenharia às atividades de
desenvolvimento de software é o alicerce para projetos de sistemas complexos, a custos
viáveis e previsíveis.
Dessa forma, a especialização de profissionais nessa área tornou-se necessária
para se alcançar o nível de excelência exigido. Nesse contexto, a elaboração de um
estudo onde o conhecimento da engenharia de software foi compilado (SWEBOK 2004)
por uma comunidade científica reconhecida mundialmente (IEEE Computer Society)
exerce um papel fundamental para a organização. Este conhecimento da engenharia de
software deve ser aplicado através de suas metodologias, práticas e processos existentes.
Este trabalho procurou apresentar uma visão geral sobre a engenharia de
software e suas dez áreas de conhecimento, bem como relacioná-las com obras atuais de
especialistas da área. Dessa forma, este artigo serve como ponto de partida para a
compreensão inicial dos problemas ligados ao desenvolvimento de software, e das
medidas necessárias para torná-lo uma atividade menos imprevisível e mais gerenciável.
Referências
[SWE04] The Institute of Electrical and Electronics Engineers (2004). Guide to the
Software Engineering Body of Knowledge. Los Alamitos, Califórnia.
[PRE06] Pressman, Roger S. (2006). Engenharia de Software. McGraw-Hill. 6ª Edição.
[SOM03] Sommerville, Ian (2003). Engenharia de Software. Addison Wesley. 6ª
Edição.
[PET01] Peters, F. James; Pedrycz, Witold (2001). Engenharia de Software, Teoria e
prática. 3ª Triagem. Editora Campus.
[ADA02] Adam, Rosangela Aguiar, (2002). Abordando o problema de análise de
requisitos não funcionais em engenharia de software. Florianópolis, Universidade
Federal de Santa Catarina.
[COS05] Reis, Adalberto Faria; Costa, Ivanir da, (2005). Proposta de integração da
Engenharia de Software nas estratégias empresarias. Revista Produção v.15, n. 3, p.
448-455. Universidade Paulista.
[COR01] Cortês, M. L.; Chiossi, T. C. S (2001). Modelos de qualidade de software.
Unicamp, Campinas.
[IEEE610.12-90] IEEE Standard Glossary of Software Engineering Terminology, 1990.
[PMB04] Project Management Institute (2004). Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos. 3ª Edição.
[MCC04] McConnell, S. (2004). Code Complete: A Practical Handbook of Software
Construction, Microsoft Press, second edition.
[KER99] Kerninghan, B. W., Pike, R. (1999), The Practice of Programming, Addison-
Wesley.
[DIA06] Dias, A. P., Dalcin, S. B., D’Ornellas, M. C. (2006), Aplicando Testes em XP
com o Framework JUnit, em InfoComp – Journal of Computer Science, Vol.5 N.2.
[MYE04] Myers, G. J. (2004), The Art of Software Testing, John Wiley & Sons, second
edition.
[GUS02] Gustafson, D. A. (2002), Theory and Problems of Software Engineering,
McGraw-Hill Companies.
[PRE01] Pressman, R. S. (2001), Software Engineering – A Practitioner’s Approach,
McGraw-Hill Companies, fifth edition.
[LEH96] Lehman, M. M. (1996), Laws of Software Evolution Revisited, European
Workshop on Software Process Technology.
[NAD02] Naddeo, C. Paulo (2002). Uma taxonomia da pesquisa na área de engenharia
de requisitos. São Paulo, Universidade de São Paulo.