Você está na página 1de 12

Engenharia de Software Seus princpios e propsito

Andr F. Gallo, Flvio A. Gomes, Nelson B. Luiz, Wagner Cunha Ps-graduao em Engenharia de Projetos de Software Universidade do Sul de Santa Catarina Campus da Grande Florianpolis - Palhoa - SC
{andre,nelson,flavio}@fln.politec.com.br, wcunha@seventh.com.br

Abstract. The software engineering was born with the proposal to organize the softwares 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 softwares engineering to the reader, approaching its knowledges 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 estgio imaturo, sem abordagens prticas para a resoluo de problemas comumente encontrados dentro das empresas que desenvolvem software: prazos estourados, gastos exorbitantes com a manuteno do software, baixa qualidade e o principal, usurios insatisfeitos. Este artigo apresenta a engenharia de software ao leitor, abordando suas principais prticas e reas de conhecimento, ilustrando uma possvel soluo para os problemas apontados.

1. Introduo
Atualmente, as empresas produtoras de software tm perseguido um objetivo em comum: produzir software com alto nvel de qualidade. Segundo Corts e Chiossi [COR01], a preocupao com a qualidade deixou de ser um diferencial competitivo e passou a ser um pr-requisito bsico para participao ativa no mercado. exatamente neste contexto, que a engenharia de software tem ganhado espao dentro das organizaes, contribuindo com mtodos, ferramentas e metodologias avanadas para a obteno de tal nvel de qualidade. O IEEE Computer Society [SWE04] define a engenharia de software como: A aplicao de uma metodologia sistemtica, disciplinada e quantificvel para o desenvolvimento, a operao e a manuteno 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 prticas engenharia de software em seus projetos de software.

2. reas de conhecimento da engenharia de software


O IEEE Computer Society, atravs 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 informaes fornecidas pelos usurios de software. Isto inclui um conjunto de tarefas que levam a um entendimento melhor de qual ser o impacto do software sobre o negcio, do que o cliente quer e de como os usurios finais vo interagir com o software [PRE06]. A engenharia de requisitos est subdivida em 4 reas, a saber: elicitao, anlise, especificao e validao dos requisitos de software [SWE04]. Nesse modelo, cada uma das atividades desenvolvidas podem ser resumidas na seguinte tabela:
Tabela 1. Subreas da engenharia de requisitos.

Elicitao

Consiste na identificao dos requisitos a partir de consulta aos stakeholders, da anlise de documentos, da anlise de informaes do domnio e/ou de estudos de mercado. e Consiste na anlise detalhada dos requisitos com a negociao entre os diferentes stakeholders visando decidir quais os requisitos que sero aceitos. Os requisitos aprovados na atividade de anlise e negociao devem ser registrados em um documento apropriado, em nvel de

Anlise Negociao Especificao

detalhamento adequado. Validao Aps a especificao e documentao, os requisitos devem sofrer cuidadosa verificao de consistncia e completitude.

Um requisito de software uma descrio dos principais recursos de um produto de software, seu fluxo de informaes, comportamentos e atributos, fornecendo uma estrutura bsica para o desenvolvimento de um produto de software. O grau de compreensibilidade, preciso e rigor da descrio fornecida por um documento de requisitos de software tende a ser diferente proporcionalmente ao grau de qualidade do produto resultante [PET01]. Sob essa perspectiva, teramos duas categorias de requisitos: aqueles responsveis pela funcionalidade do sistema e aqueles responsveis por qualidades que devam estar presentes, tais como desempenho, integridade, disponibilidade e segurana. Os primeiros so denominados requisitos funcionais e os ltimos requisitos no funcionais [NAD02]. Os requisitos possuem uma natureza voltil. Diversos fatores contribuem para sua instabilidade ao longo do tempo: mudanas externas no ambiente (mudanas de legislao, mudanas no mercado, mudana no posicionamento estratgico da empresa), erros incorridos no processo de requisitos, entre outros. Todos esses fatores fazem com que seja necessrio alterar os requisitos. Tais alteraes precisam ser conduzidas de forma ordenada para que no 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 direes do processo de software e durante todo o seu ciclo de vida. Esta tarefa importante, pois permite avaliar o impacto quando ocorrer uma mudana. Para auxiliar nessa atividade, a indstria de software comeou a desenvolver ferramentas para gerenciar requisitos [NAD01]. No contexto da engenharia de requisitos, uma rea de extrema relevncia ao desenvolvimento de software de forma geral, h a necessidade de introduzir o processo de gerenciamento de requisitos, permitindo o acompanhamento, a evoluo, a deteco e correo de problemas de forma sistmica, garantindo a qualidade dos artefatos gerados para as prximas fases.

2.2. Design de software


O design ou projeto de software comea quando a primeira iterao da engenharia de requisitos concluda. O objetivo do projeto de software aplicar um conjunto de princpios, conceitos e prticas que levam ao desenvolvimento de um sistema ou produto de alta qualidade [PRE06]. O design de software vai de uma viso global do software a uma viso mais concentrada que define o detalhe necessrio para implementar o sistema. O processo comea enfocando a arquitetura, no qual subsistemas so definidos, mecanismos de comunicao entre sistemas so estabelecidos, componentes so identificados e uma

descrio detalhada sobre cada componente desenvolvida. Adicionalmente interfaces internas e externas com o usurio so projetadas [PRES06]. Alm da arquitetura propriamente dita, ao longo dos anos, foram criadas solues 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 padres de projeto existentes (quando eles satisfazem s necessidades do projeto) em vez de criar outros [PRES06].

2.3. Construo de software


Esta rea de conhecimento da engenharia de software trata dos conceitos relacionados criao de software executvel, os quais incluem a codificao, verificao, testes de unidade e de integrao, e depurao. Possui ligaes com todas as demais reas de conhecimento, mas principalmente com as reas de design e testes, pois muito do processo de construo 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 combinao tratada como uma atividade da fase de construo. Entretanto, as atividades de construo de software esto 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 so responsveis por 50 a 75 por cento dos erros totais [MCC04], fatores que demonstram a necessidade de estudo de melhores prticas nessa rea. Esse estudo deve incluir os princpios fundamentais da construo de software: reduo de complexidade, antecipao de mudanas, estruturao para verificao e uso de padres, alm das atividades de gerenciamento da construo e das consideraes prticas pertinentes rea, visto que a rea de conhecimento de construo a que est mais ligada a atividades prticas [SWE04]. A reduo de complexidade alcanada atravs da utilizao de padres e normas de construo e da criao de cdigo simples e legvel. Kerninghan [KER99] considera esta simplicidade e clareza so a base para a construo de software inteligvel e gerencivel, que combinados estruturao para verificao permitem revises de cdigo e facilitam os testes, alm de apoiar a antecipao de mudanas. O gerenciamento da construo est relacionado ao modelo e ao mtodo de desenvolvimento escolhido, os quais influenciam a habilidade do projeto de contemplar esses princpios fundamentais da construo. As atividades de gerenciamento, como as mtricas, por exemplo, esto ligadas a rea de conhecimento da engenharia de processo. As consideraes prticas relacionadas rea de construo incluem as atividades de design durante a construo, as linguagens de construo empregadas, a codificao, os testes de unidade e de integrao, a reutilizao de cdigo, a qualidade de construo, e a integrao dos componentes de software.

2.4. Teste de software


A rea de conhecimento de testes de software compreende as atividades desenvolvidas para a avaliao da qualidade do software, atravs da identificao de defeitos e problemas. Essa verificao compreende a execuo de um conjunto finito de casos de teste, adequadamente retirados de um domnio geralmente infinito de possibilidades, e a sua comparao com os resultados esperados [SWE04]. Essa definio inclui os princpios fundamentais da atividade de teste: a execuo de testes, para diferenci-la das atividades de anlise esttica do cdigo; o conjunto finito de testes, pois so raros os softwares onde possvel um teste exaustivo de todas as possibilidades; a seleo adequada dos casos de testes, que est relacionada tcnica e aos critrios de teste escolhidos; e por fim a comparao com os resultados, o que implica na especificao dos critrios de aceitao dos testes [GUS02]. A rea de testes de software est ligada diretamente s reas de conhecimento de construo, manuteno e qualidade de software. importante ressaltar que diferentemente da rea de qualidade de software, a rea de testes focada apenas nos testes dinmicos, ou seja, os que compreendem execuo de cdigo. As atividades de testes devem englobar todo o processo de desenvolvimento e manuteno, inclusive com a elaborao dos planos e procedimentos de testes j nas primeiras fases do processo de requisitos, e com o refinamento dos mesmos durante a evoluo do desenvolvimento [SWE04]. Alm disso, as atividades de testes devem ser executadas em diferentes nveis de igual importncia, que so os testes de unidade, testes de integrao e testes do sistema. Para cada nvel, os testes devem ser conduzidos sob a viso de objetivos especficos, como, por exemplo, os testes de aceitao de acordo com os requisitos, testes de instalao, testes de conformidade com a especificao, testes de desempenho, entre outros. As tcnicas de testes de software so classificadas em black-box - que so os testes que levam em considerao apenas a verificao de entradas e sadas, sem acesso as estruturas internas do software; e white-box testes baseados no design e no cdigo do software; e a combinao de elementos de ambas as tcnicas deve ser base para uma estratgia de testes razovel [MYE04].

2.5. Manuteno de software


Mesmo aps a concluso de uma campanha de testes eficiente, o software desenvolvido ainda pode conter falhas. Alm disso, o ambiente de operao de um software muda com o decorrer do tempo, e o software precisa acompanhar essas mudanas. Dessa forma, a rea de manuteno de software compreende as atividades necessrias para fornecer suporte a software de maneira eficiente e vivel, e por sua abrangncia est ligada a todas as demais reas de conhecimento da engenharia de software [SWE04]. Essa necessidade de adaptao e evoluo contnua inerente ao software, visto que com o decorrer do tempo surgem diferenas entre o software e o seu ambiente operacional, e essa evoluo deve ocorrer atravs de um processo controlado de feedback e manuteno, caso contrrio o grau de satisfao com o software em execuo ir decair com o tempo [LEH96].

A manuteno de softwares existentes responsvel por mais de 60 por cento do esforo empregado por uma organizao de desenvolvimento, e este valor tende a aumentar conforme mais softwares so produzidos [PRE06]. As atividades de manuteno incluem as realizadas antes da entrega do software, como o planejamento de manuteno, ou ps-entrega, como a correo de falhas ou desenvolvimento de melhorias. De acordo com Pressman [PRE06] so divididas em quatro categorias: manuteno corretiva, manuteno adaptativa, manuteno perfectiva, e manuteno preventiva. Os pontos chaves da manuteno de software se referem s tcnicas de compreenso do software a ser modificado e reengenharia e engenharia reversa de software, os testes para garantir que as modificaes no geraram efeitos colaterais, a anlise de impacto das alteraes solicitadas, e a promoo da manutenibilidade do software. Alm disso, alguns pontos devem ser considerados no aspecto gerencial, como o alinhamento com os objetivos da organizao, a definio do processo de manuteno, e at mesmo o outsourcing desta atividade [SWE04]. O processo de manuteno definido por etapas semelhantes ao processo de desenvolvimento, como a anlise, projeto, codificao, testes e documentao, e por atividades que so nicas ao processo de manuteno, como a anlise de impacto de alteraes, a reviso e aceitao de modificaes, as atividades de suporte do software, e o planejamento de manuteno de um software. Outro elemento crtico da manuteno de software o processo de gerncia de configurao, que difere da gerncia de configurao do desenvolvimento pela quantidade de pequenas alteraes que precisa ser controlada em um software operacional. Alm disso, um processo de controle de qualidade de software precisa ser definido e aplicado para dar suporte a atividade de manuteno.

2.6. Gerenciamento da configurao de software


Uma disciplina da engenharia de software que vem ganhando crescente destaque em projetos de software a gerncia de configurao do software, ou software configuration management SCM. A razo 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 sada deste software. Assim, o gerenciamento de configurao, mais comumente chamado de gesto de configurao de software, o desenvolvimento e a aplicao de padres e procedimentos para gerenciar um produto de sistema em desenvolvimento. Esse gerenciamento necessrio porque na medida em que ele se desenvolve so criadas verses diferentes de software que incorporam propostas de mudanas, correes de defeitos e adaptaes. possvel que haja vrias verses em desenvolvimento e em uso ao mesmo tempo, sendo necessrio manter o controle das mudanas que foram implementadas e de como essas mudanas foram includas no software. Segundo Pressman [PRE06], a sada do processo de software a informao, que pode ser dividida em trs categorias: programas de computador, produtos de trabalho e dados. Os itens que compreendem toda a informao produzida como parte do processo de software so chamados coletivamente de configurao 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 modificao pode ocorrer em qualquer poca por qualquer motivo. Os processos relacionados SCM possuem basicamente as seguintes atividades: implementao do processo, identificao da configurao, controle da configurao, relato da situao, avaliao da configurao, e gerncia de liberao de entrega [SWE04]. O sucesso do projeto de software est muitas vezes associado com a adoo de processos de software como o de SCM. Porm, a adoo desses processos uma tarefa complexa que muitas vezes acaba por inviabilizar as empresas em sair do diagnstico, onde se observa a necessidade em implantar o processo, para chegar ao operacional, onde se tem a execuo destes processos nos projetos de software. Isto se deve muitas vezes ao fato de se acreditar que a implantao de processos de software em uma empresa de software, como o caso da implantao do processo de SCM, ocorre simplesmente pela adoo de ferramentas. No entanto, a maior parte dos custos envolvidos nesta implantao relaciona-se a gastos com recursos humanos e na estruturao organizacional. O processo de SCM apia 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 vrios setores da organizao. Alm disso, os processos de SCM, no perodo de implantao, podem acarretar uma maior lentido do processo de desenvolvimento de software, incorporando prticas muitas vezes vistas como burocrticas.

2.7. Gerenciamento da engenharia de software


O gerenciamento da engenharia de software pode ser definido como a aplicao do gerenciamento das atividades, do planejamento, da coordenao, da mensurao, do monitoramento, do controle e do nvel de reportagem, para assegurar que o desenvolvimento e a manuteno do software sistemtica, 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 prpria engenharia de software. Este gerenciamento realizado atravs da aplicao e da integrao dos seguintes processos de gerenciamento de projetos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento [PMB04]. Cada processo tem sua importncia dentro do projeto, sendo este da natureza de software ou de qualquer outra, porm, outro fator de suma importncia a das pessoas que fazem parte do projeto. Sem uma equipe bem motivada e gerenciada, os processos necessrios para controlar e gerenciar a engenharia de software no sero aplicados com eficcia.

2.8. Processo de engenharia de software


No desenvolvimento de software, existe uma seqncia de atividades que produzem uma variedade de documentos e um programa executvel, que compreende um conhecimento aplicado. Estas atividades da engenharia so conhecidas por processo de software. O processo de engenharia de software subdividido em 4 reas: Implementao e mudana do processo, definio do processo, verificao do processo e mensurao do processo e do produto [SWE04]. A definio do processo uma fase importante, onde verificado qual modelo de processo ou ciclo de vida de software ser adotado. Atualmente, inmeros modelos de ciclo de vida de software so utilizados e os mais comuns so: modelo de clico de vida clssico, modelo espiral, modelo incremental, modelo de prototipao e modelo espiral para crculo. Como exemplo, a figura abaixo traz a ilustrao do modelo de vida clssico, tambm conhecido como modelo em cascata. Este modelo o paradigma mais antigo da engenharia de software, por sugerir uma abordagem sistemtica e seqencial para o desenvolvimento de softwares.

Figura 3. Modelo de ciclo de vida clssico ou em cascata.

Para Fowler & Scott, no existe um nico processo para o desenvolvimento de software. Vrios fatores associados com o desenvolvimento de software levam a vrios tipos de processos. As equipes devem criar seus prprios processos, utilizando processos publicados como orientao e no como padres a serem seguidos (Fowler & Scott, 2000 p.30). Portanto, o no 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 considerao as caractersticas do projeto, como equipes disponveis, ferramentas a serem utilizadas, aplicao de padres existentes, infra-estrutura e etc.

2.9. Ferramentas e mtodos da engenharia de software


O acrnimo CASE, computer-aided software engineering (engenharia de software com auxlio de computador) se refere a uma gama de diferentes tipos de programas utilizados para apoiar as atividades do processo de software, como a anlise de requisitos,

modelagem de sistema, a depurao e os testes. Todos os mtodos atualmente so fornecidos com tecnologia CASE associadas, como no caso de editores para anotaes utilizadas no mtodo, mdulos de anlise que verificam o modelo do sistema de acordo com as regras de negcios e geradores de relatrios para ajudar na criao do sistema [SOM03]. A engenharia de software abrange um conjunto de trs elementos fundamentais mtodos, ferramentas e procedimentos que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construo de software de alta qualidade e produtivamente. As ferramentas de engenharia de software proporcionam apoio automatizado ou semi-automatizado aos mtodos, sendo denominadas de ferramentas CASE. As ferramentas CASE podem ser classificadas por funo, por seus papis como instrumentos para os gerentes e para o pessoal tcnico, pelo uso que elas tm nas vrias 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 funo como critrio primordial: ferramentas de planejamento de sistemas comerciais; ferramentas de gerenciamento de projetos; ferramentas de anlise e projeto; ferramentas de programao; ferramentas de prototipao; ferramentas de manuteno; ferramentas de integrao e testes; ferramentas de estrutura; e suporte [PRE06]. Os tipos de ferramentas so [PRE06]: ferramentas de planejamento, ferramentas de edio, ferramentas de gerncia de mudanas, ferramentas de gerncias de configurao, ferramentas de prototipao, ferramentas de apoio a mtodos, ferramentas de processadores de linguagem, ferramentas de anlise de programas, ferramentas de testes, ferramentas depurao, ferramentas de documentao 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 so aplicadas no decorrer de todo processo. A ferramenta CASE compreende um conjunto de blocos de construes que se inicia em um nvel de hardware e software de sistema operacional e termina em ferramentas individuais [PRE06].

2.10. Qualidade de software


A gesto da qualidade de software talvez seja o tema mais discutido dentro do mundo de informtica atual. Isso se d, em grande parte, pela falta de adoo de uma boa poltica 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 nvel razovel. Existem diversas definies para qualidade. Para Crosby, qualidade significa a conformidade dos requisitos do usurio (SWEBOK, 2004, apud Crosby P., 1979). J para Humphrey, qualidade significa atingir nveis excelentes de aptido para o uso do software. (SWEBOK, 2004, apud Humphrey W., 1989). Uma definio mais

abrangente e atual foi dada pela norma ISO9001-2000, onde qualidade definida como o grau em que um conjunto de caractersticas inerentes cumprem suas exigncias. Um erro comumente encontrado dentro das organizaes 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 implementao das correes necessrias. Com o intuito de evitar este cenrio, as empresas produtoras de software esto adotando metodologias que garantam a qualidade em todo o processo de desenvolvimento de software. Abaixo, uma lista identifica as principais metodologias, padres e normas que utilizadas: a) Norma ISO 9001:2000. Descreve os elementos de garantia de qualidade em termos genricos, que podem ser aplicados a qualquer negcio independentemente dos produtos ou servios oferecidos. 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. 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 alcanar seu resultado esperado.

b)

c)

3. Concluso
Os softwares e sistemas computacionais afetam profundamente o desenvolvimento econmico das naes. A aplicao dos conceitos de engenharia s atividades de desenvolvimento de software o alicerce para projetos de sistemas complexos, a custos viveis e previsveis. Dessa forma, a especializao de profissionais nessa rea tornou-se necessria para se alcanar o nvel de excelncia exigido. Nesse contexto, a elaborao de um estudo onde o conhecimento da engenharia de software foi compilado (SWEBOK 2004) por uma comunidade cientfica reconhecida mundialmente (IEEE Computer Society) exerce um papel fundamental para a organizao. Este conhecimento da engenharia de software deve ser aplicado atravs de suas metodologias, prticas e processos existentes. Este trabalho procurou apresentar uma viso 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 compreenso inicial dos problemas ligados ao desenvolvimento de software, e das medidas necessrias para torn-lo uma atividade menos imprevisvel e mais gerencivel.

Referncias
[SWE04] The Institute of Electrical and Electronics Engineers (2004). Guide to the Software Engineering Body of Knowledge. Los Alamitos, Califrnia. [PRE06] Pressman, Roger S. (2006). Engenharia de Software. McGraw-Hill. 6 Edio. [SOM03] Sommerville, Ian (2003). Engenharia de Software. Addison Wesley. 6 Edio. [PET01] Peters, F. James; Pedrycz, Witold (2001). Engenharia de Software, Teoria e prtica. 3 Triagem. Editora Campus. [ADA02] Adam, Rosangela Aguiar, (2002). Abordando o problema de anlise de requisitos no funcionais em engenharia de software. Florianpolis, Universidade Federal de Santa Catarina. [COS05] Reis, Adalberto Faria; Costa, Ivanir da, (2005). Proposta de integrao da Engenharia de Software nas estratgias empresarias. Revista Produo v.15, n. 3, p. 448-455. Universidade Paulista. [COR01] Corts, 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 Edio. [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, AddisonWesley. [DIA06] Dias, A. P., Dalcin, S. B., DOrnellas, 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 Practitioners 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. So Paulo, Universidade de So Paulo.

Você também pode gostar