ENGENHARIA DE SOFTWARE

BENEFCIOS DA APLICAO BASEADO EM CASO DE USO

Jonathas Montenegro Souza Pita

Prof. Jean Richard
Centro Universitrio Leonardo da Vinci UNIASSELVI
Gesto de Tecnologia da Informao (GTI0072) Trabalho de Graduao
20/05/15
RESUMO
O desenvolvimento de software surgiu com o objetivo de criar solues,
aumentar a produtividade, possibilitar melhorias de processos alm de criar novas
alternativas atravs do uso da inteligncia computacional. Atravs desta premissa, este
estudo visa apresentar a Engenharia de Software como proposta de mtricas e modelos
no desenvolvimento e tambm em como o seu uso pode ser benfico, tanto para a
equipe de desenvolvimento quanto para o usurio final atravs de uma aplicao
prtica utilizando um objeto de estudo.
Palavras-chave: Engenharia; Software; Desenvolvimento de software.
1 INTRODUO
A Engenharia de Software foi definida pela primeira vez como o
estabelecimento e uso de slidos princpios de engenharia para que se possa obter
economicamente um software que seja confivel e que funcione eficientemente em
mquinas reais (PRESSMAN, 1995). Deste conceito entende-se que atravs de
metodologias sistematizadas a engenharia direciona o desenvolvimento de forma
torn-lo mais eficiente, seguro e gil.
Como capacidades essenciais crticas no processo de desenvolvimento de novos
produtos, pode-se citar fatores ligados a quatro dimenses bsicas: a estratgia
tecnolgica, o contexto organizacional, as equipes de projetos e as ferramentas para
melhorar continuamente o processo. Atravs deste pensamento, percebe-se que
Schilling e Hill propm a conduo das iniciativas de desenvolvimento de novos
produtos sob a forma de projetos. (SCHILLING; HILL, 1998)
Um software surge a partir de um problema e do entendimento claro deste e a
partir deste conhecimento a busca pela soluo que ser ento desenvolvida a partir de
escopos, mtodos, estudo de possibilidades entre outros requisitos. Este trabalho possui
o intuito de apresentar um caso prtico de uso da Engenharia de Software no

entendimento do problema e desenvolvimento da soluo. Doravante, apresentando os

benefcios e as dificuldades da aplicao.
2 ENTENDIMENTO DO CASO DE USO
Devido ao aumento de fatores como produtividade, faturamento, nmero de
filiais e funcionrios, uma empresa de vendas, que aqui ser chamada Empresa A,
comeou a ter problemas em processos simples como cadastros de clientes e a
comunicao ordenada entre os setores de forma que o prprio andamento passou a ser
prejudicado. Mesmo aps definidos melhorias de processos e a implantao de um ERP
que mantm e apresenta os dados cadastrados viu-se a necessidade clara de implantar
uma ferramenta que gerenciasse as solicitaes de cadastro de novos clientes, novos
produtos, novas anlises de crdito e que a partir destes dados cadastrados apresentar
indicadores de desempenho.
O principal objetivo do sistema a ser desenvolvido controlar as solicitaes de
cadastro e gerar indicadores de atendimento do setor de cadastro.
3 PROCESSOS DE SOFTWARE
Conforme PMI(2004, p.5) Um projeto um esforo temporrio para criar um
produto, servio ou resultado exclusivo. Temporrio, significa que o resultado
gerado, de certa forma, de maneira diferente de outros produtos servios ou resultados
j existentes. Martin e Tate (2001, p.8), ressaltam o fato dos projetos serem temporrios
e produzirem resultados nicos, em contraponto com as operaes continuadas, em que
o mesmo processo repetido vrias vezes, com objetivo de produzir os mesmos
resultados a cada execuo. Ainda, o plano de trabalho incerto, requerendo
atualizaes constantes, enquanto nas operaes continuadas o plano bem definida.
Segundo PRESSMAN(1995), para que um projeto de desenvolvimento de
software seja bem sucedido, necessrio que alguns parmetros sejam analisados, como
por exemplo o escopo do projeto, os riscos envolvidos, os recursos necessrios, as
tarefas a serem realizadas, os indicadores a serem acompanhados, os esforos e custos
aplicados e a sistemtica aplicada. Porm o maior desafio de para qualquer metodologia
de software definir quando cada fase do projeto dever iniciar e encerrar. Pode parecer
uma tarefa simples criar um cronograma pois existe uma ordem nas tarefas, porm
deve-se levar em conta os erros que ocorrem ocorrer sem agentes externos. Mas atravs

de modelos de ciclos de vida, pode-se sistematizar as etapas do desenvolvimento de

forma mais concisa.
3.1 MODELOS DE CICLO DE VIDA
Um dos modelos de ciclo de vida mais simples conhecidos o chamado Cascata
ou Clssico. Nele no so considerados agentes externos e as fases so baseadas nos
passos bsicos para qualquer desenvolvimento. So eles: requisitos de sistema,
requisitos de software, analise, design de programa, codificao, testes e operao
conforme ROYCE (1970). O grande paradigma deste modelo o fato do produto ser
entregue em sua totalidade, e no se aplica ao caso de uso. Se viu necessrio o
desenvolvimento de uma primeira verso da soluo para atender as necessidades mais
bsicas e em um prximo passo liberar novas verses conforme novas funcionalidades
forem desenvolvidas.
Outro modelo de ciclo de vida o chamado Prototipao. Este possui como
maior caracterstica garantir clareza no entendimento dos requisitos pr-definidos para
soluo do problema. Neste modelo so produzidos prottipos do produto final apenas
com a parte visual apresentada de forma a encontrar na prtica requisitos e necessidades
da aplicao.

Fonte: Portal INPE, 2015

esta apresentao preliminar da soluo que garante confiabilidade e elimina

grande parte dos retrabalhos, mas importante citar que existem dois pontos negativos
de aplicar este modelo ao caso de estudo. O primeiro ponto a necessidade de

desenvolver uma aplicao preliminar o que toma tempo e recursos. E um segundo

ponto negativo o fato de que modelos preliminares da aplicao podem gerar um
falso entendimento do tempo necessrio para o desenvolvimento dando a entender que o
desenvolvimento das funcionalidades em si demandam menos recursos.
Apesar dos pontos negativos, este modelo o que melhor se aplica ao caso de
uso.
Existem ainda as chamadas metodologia geis. Estes modelos se popularizaram
em 2001 com a apresentao do Manifesto gil (Agile Manifesto 2004), onde dezessete
especialistas em processo de desenvolvimento estabeleceram princpios e observncias
comuns entre os mtodos geis. Os conceitos chave destas metodologias que se opem
s tradicionais so:
So adaptativas ao invs de preditivas, isto implica em aceitar alteraes de
requisitos em qualquer fase do projeto se adequando a mudanas competitivas.
So orientadas s pessoas e no a processos, valorizando o trabalho de cada
indivduo relacionado ao projeto, desde fornecendo um ambiente de trabalho adequado
e motivao para a equipe at participao do cliente e o entendimento de suas
necessidades.
Buscam o equilbrio entre a excelncia do desenvolvimento e agilidade da
entrega priorizando a funcionalidade do software, continuidade das aes, eliminar o
mximo possvel de retrabalho e atravs de reunies frequentes ponderar os pontos
fracos para tornar a equipe mais efetiva.
4 DEFININDO REQUISITOS
O Desenvolvimento de um sistema de software centrado na arquitetura, inicia-se
com um arquiteto de software, de posse de um conjunto de requisitos do sistema. Nesse
momento, busca-se identificar qual estilo ou combinaes destes oferece suporte mais
adequado a esses requisitos e, portanto, derivar uma arquitetura de software que atenda
s caractersticas do sistema a ser desenvolvido. Conforme a definio abaixo
(DORFMAN, THAYER 1990):
Requisito funcional: utilizando ponto de vista do usurio, um requisito de
sistema de software que especifica uma funo que o sistema ou componente deve ser
capaz de realizar. Estes so requisitos de software que definem o comportamento do

sistema, ou seja, o processo ou transformao que componentes de software ou

hardware efetuam sobre as entradas para gerar as sadas.
Requisito no funcional: aquele que descreve como que o sistema efetuar as
aes. No diretamente quanto as funcionalidades mas em como o sistema executar
estas funcionalidades.
Segundo CYSNEIROS & LEITE(1997), os requisitos no funcionais, ao
contrrio dos funcionais, no expressam nenhuma funo a ser realizada pelo software
e sim comportamentos e restries que este software deve satisfazer.
4.1 REQUISITOS FUNCIONAIS DO CASO DE USO
Em anlise ao caso de uso, foi definido juntamente com gestores e diretores
todos os requisitos e elaborado um documento contendo todos eles atravs da seguinte
estrutura:
A. Descrio geral do sistema.
B. Requisitos funcionais.
B.1 Cadastro
[RF01] Criar solicitao;
[RF02] Alterar solicitao;
[RF03] Excluir solicitao;
B.2 Visualizao
[RF04] Visualizar solicitaes criadas;
[RF05] Visualizar indicadores de desempenho;
B.2 Notificao
[RF05] Enviar e-mail para solicitante e para setor de cadastro quando uma nova
solicitao criada;
[RF06] Enviar e-mail para solicitante e para setor de cadastro quando uma
solicitao promovida para uma nova fase;
[RF07] Enviar e-mail e para setor de cadastro quando ultrapassado prazo limite
de finalizao da solicitao;
[RF08] Usurio enviar notificao solicitando reavaliao de cadastro j
efetuado;
B.3 Importao e exportao

[RF09] Anexar arquivo ao efetuar cadastro;

[RF10] Exportar relatrios de cadastros efetuados;
[RF11] Exportar relatrios de tempo mdio de finalizao dos cadastros;
C. Requisitos no funcionais
[RN01] Expirar sesso do usurio aps uma hora;
[RN02] Flexibilidade em manutenes corretivas e criao de novos tipos de
solicitaes;
[RN03] Perfis de acesso diferenciados para leitura, alterao e excluso e
bloqueio de acesso fora do nvel;
[RN04] Usabilidade e intuitividade de forma que no seja necessrio
treinamento especializado para uso;
[RN05] Desenvolvimento utilizando plataforma PHP5 em servidor APACHE2 e
utilizando banco de dados MySQL com acesso pela intranet empresarial.
[RN06] Utilizar comunicao LDAP de servidor AD para login e recolher dados
como e-mail e setor do usurio.
[RN07] Garantir integridade dos dado atravs de validaes automticas
5 DESIGN DE SOFTWARE
Pfleeger (2004, p. 159) nos ensina que o design de software o processo
criativo de transformar o problema em uma soluo. , portanto, a descrio da
estrutura a ser construda para que o software realize as funes desejadas.
5.1 MODELO CONCEITUAL
Uma descrio do sistema proposto em termos de um conjuntos de ideias e
conceitos integrados a respeito do que ela deve fazer, de como deve se comportar e com
o que deve se parecer que seja compreendida pelos usurios da maneira pretendida.
No objeto de estudo, pode ser feita a seguinte descrio:
Aplicao web de uso interno da empresa que crie, altere, exclua e promova
solicitaes de cadastro de novos clientes. O Vendedor deve inserir os dados do cliente
confirmar e os dados so salvos no sistema. Neste momento o setor de cadastro recebe
uma notificao por e-mail informando que existe um novo cadastro, ento abre o e
completa os dados. A solicitao deve passar, ao todo, por 4 estgios: em cadastro,
anlise de crdito, concludo ou rejeitado. Cada vez que um cadastro promovido o

solicitante deve receber um e-mail de notificao informando o status. A partir dos

dados apresentar relatrios e indicadores de desempenho do setor de cadastro.
5.2 ARQUITETURA DE SOFTWARE
Pode-se assumir arquitetura de software como o entendimento das partes do
sistema a ser desenvolvido como subsistemas e mdulos que atendero os requisitos
propostos. Quo maior forem os requisitos, em maior escala ser a arquitetura a ser
desenvolvida que segundo Sommerville (2003) pode depender principalmente dos no
funcionais como desempenho, proteo, segurana e disponibilidade. Destes itens,
aqueles que forem os mais requisitados sero os definidores do modelo de arquitetura a
ser utilizado.
No caso do objeto de estudo, foi definido que a segurana nos dados seria o
principal pilar, seguido pelo desempenho. Dentro do conceito de segurana est
confiabilidade dos dados na aplicao e no tratamento destes dados.
5.3 MODULARIDADE
Conforme Abelson e Sussman (1985), a sntese efetiva de programas tambm precisa
de prncipios organizacionais que nos guie na formulao do desenho de um programa.
Em particular, precisamos de estratgias para nos ajudar a estruturar grandes sistemas de
tal maneira que eles tenham uma organizao modular, ou seja, possam ser divididos em
partes coerentes que possam ser separadamente desenvolvidas. Quando os requisitos
direcionam a aplicao de forma que suas aes seja independentes, o ideal que os
mdulos se tornem mais independentes um dos outros para facilitar a manuteno e o
desenvolvimento individual por exemplo.
Quando se trata de modularidade, define-se que acoplamento se refere ao quanto
a unidade funcional depende da outra para funcionar, quanto maior a dependente entra
estas unidades, sejam elas mtodos, funes ou classes por exemplo, maior o
acoplamento. A coeso, por sua vez, est ligada responsabilidade nica da unidade
funcional, um mtodo que seja coeso realiza uma funo conceitual, servindo a apenas
um propsito especfico.
Com estes conceitos em mente, entende-se que para o o objeto de estudo, o
desenvolvimento deve ser voltado para a alta coeso e a baixa modularidade, pois um
dos objetivos da aplicao se tornar base para outras solues semelhantes mas

independentes uma da outra criando uma aplicao nica mas composta de solues
especficas e autnomas.
5.4 INTERFACE DE USURIO
Interface o nome dado a toda poro de um sistema com a qual um usurio
mantm contato ao utiliz-lo. Conforme conceitua Preece (1994), iterao o processo
de comunicao entre pessoas e sistemas interativos de forma interpretativa e tendo este
conceito em mente, pode-se entender a interface como o sistema de comunicao
utilizando neste processo.
A interface de usurio deve ser entendida como sendo parte de
um sistema computacional com a qual uma pessoa entrar em
contato fsica, perceptiva ou conceitualmente. Sendo que fsica
se tratando dos elementos que o usurio pode manipular,
perceptiva aqueles que ele pode perceber e conceitual que o
resultado da interpretao e do raciocnio do usurio
desencadeados pela usa interao com o sistema (MORAN
1981).

Para no ser necessrios longos treinamentos, a intuitividade da interface um

item prioritrio a ser considerado na hora de planejar o design das telas. Itens como
menu fixo no top da tela, formulrios de cadastro bem posicionados e com letras
legveis, ttulos escolhidos para descreverem as aes a serem executadas. Mas se
tratando de um sistema consideravelmente simples, a interface no apresentou grandes
dificuldades, apenas foram aplicados conceitos bsicos de legibilidade e facilidade no
uso.
6 DESENVOLVIMENTO DE SOFTWARE
Parte do projeto de software que demanda maior esforo da equipe tcnica. Com
o escopo da soluo bem resolvido e o cerne devidamente claro, possvel iniciar o
processo de desenvolvimento que se inicia planejando a infraestrutura e plataforma de
desenvolvimento a ser usada.

6.1 PLATAFORMA DE DESENVOLVIMENTO

A escolha correta da plataforma de desenvolvimento ser o alicerce do sistema,,
a escolha errada poder gerar transtornos em termos de manuteno, correes,
melhorias, mantenimento e integraes. Durante a pesquisa das plataformas ficou claro
alguns itens importantes serem levados em consideraes:
Referncias de mercado:

Recomendaes por empresas que utilizam a

plataforma, analisar solues j desenvolvidas, pontuar prs e contras e qual aceitao

do mercado para aplicaes que utilizam esta plataforma.
Custo em recursos humanos: A falta de popularidade na linguagem a ser
utilizada em geral significa mo de obra mais escassa e cara incluindo tambm o custo
em treinamento que para linguagens mais especializadas pode significar altos preos.
Atualizaes: Um alto nvel de atualizaes em um plataforma indica uma
linguagem no consistente e com alta ocorrncia de falhas que podem gerar transtornos.
Legalidade: Algumas plataformas so livres apenas para uso particulas e
educacional, mas para uso comercial so pagas, existem tambm plataformas totalmente
pagas. Optar por uma distribuio paga vai depender do que esta linguagem tem a
oferecer que se aplica aos requisitos e o quanto este custo vale a pena para o retorno
final da aplicao.
Suporte: Algumas plataforma de desenvolvimento possuem suporte pago que
pode auxiliar a equipe de desenvolvimento. As distribuies gratuitas por sua vez,
costumam ter fruns de ajuda e discusso que podem substituir certos atendimentos
pagos. Cabe analisar o nvel dos desenvolvedores.
Aplicao dos requisitos: claro que o sucesso final depende que a aplicao
cumpra todos os requisitos apontados e escolher um plataforma que auxiliar nisto um
passo para a entrega de um projeto bem sucedido.
Tendo em vista todos estes fatores a soluo, entre as linguagens Java, PHP e
ASP a escolhida foi PHP5. Esta foi originada a partir da linguagem conhecida como
PHP/FI criada em 1994 por Ramus Lerdof, e ao longo dos anos seguintes foi sendo
aperfeioada. Em 1998 o desenvolvimento passou a ser feito por vrios desenvolvedores
e ento passou a ser chamada apenas de PHP, como acrnimo recursivo Hypertext
Preprocessor. Ainda neste perodo, j disponibilizava uma interface robusta de
mltiplos banco de dados como Oracle, SQL e Sybase, ou protocolos como IMAP,
LDAP e POP3, ou APIS e a possibilidade de desenvolvimento de novas bibliotecas.

Hoje, na verso 5, pode-se apontar as seguintes caractersticas: velocidade, orientao

objetos, portabilidade, open-source e ser server-side, ou seja, o servidor executa as
aes e retorna como HTML ou Javascript.
Enquanto o PHP uma linguagem server-side, o HTML e o Javascript por sua
vez so client-side, ou seja, suas aes so executadas a nvel da sesso do utilizador. E
para o Javascript exitem bibliotecas que trazem recursos prontos como o AJAX
(Asynchronous Javascript and XML) que permite tornar as aes se tornem mas
responsivas dentro da pgina executando diretamente na sesso atual sem necessidade
de atualizao. A biblioteca Jquery possui funes predefinidas que executam funes
integradas com o AJAX. O framework EasyUI uma biblioteca do Jquery que possui de
forma mais abstrata e simplificada itens de interface como cones, barras de tarefas,
tabelas dinmicas ou efeitos grficos.
Segundo W3TECHS(2015), o PHP utilizado por 81,8% dos websites como
uma linguagem server-side. Ao contrrio da linguagem Java que possui 30% de
utilizao.
6.2 AMBIENTE DE DESENVOLVIMENTO
Apenas escrevendo os cdigos de forma desordenada a probabilidade de no
cumprir os requisitos corretamente bem alta, por isso a importncia de um ambiente
onde o desenvolvimento posso ocorrer de forma organizada e segura. Existem algumas
opes de uso como Eclipse, Delphi, Visual Studio, mas dentre as vistas o Netbeans foi
o melhor soluo apresentada. As vantagens de se utilizar uma ferramenta de ambiente
de desenvolvimento a possibilidade de criar partes de cdigo de forma automtica,
notificao de erros, correes automticas, depurao de cdigo, organizao das
classes e dos arquivos do projeto.
Um problema no desenvolvimento em equipe alteraes de cdigo
simultneas, a soluo encontrada para isso foi uma ferramenta implantada em um
servidor linux chamada Subversion. Um projeto da empresa Apache, que integrado ao
Netbeans apresenta uma soluo inteligente para o problema do desenvolvimento
simultneo. Os arquivos da aplicao so movidos para o repositrio do Subversion e
ele ir gerenciar as alteraes efetuadas. De forma prtica um desenvolvedor pode
alterar determinado trecho de cdigo enquanto outro faz a mesma coisa. O Subversion
identifica isto e aponta ao Netbeans que por sua sinaliza o trecho no painel alterando a
cor do arquivo para vermelho indicando que naquele momento que o cdigo est sendo

atualizado. Ao finalizar o primeiro desenvolvedor confirma a alterao e o segundo

receber um notificao para decidir se sobrescreve ou no.
6.3 INFRAESTRUTURA
Aps a deciso da plataforma de desenvolvimento a infratrutura necessrio
dever ser montada. Para o PHP foi necessrio a instalao de um servidor web com
sistema operacional linux Fedora e feita a instalao dos aplicativos Apache, PHP5,
Subversion, banco de dados MySQL e PHPMyAdmin.
Outro fator importante a automatizao de backups dirios e semanais da
aplicao e do banco de dados, isto vital para dar segurana no gerenciamento de
problemas.
Outro fator primordial quanto a infraestrutura do ambiente a segurana do
software. Segundo Chess e Mcgraw (2004), um campo que surgiu a partir da
necessidade de desenvolvedores, arquitetos e cientistas da computao de lidar com a
construo de software mais seguro. De forma prtica, o software resistente a invaso
o que reduz a probabilidade de um ataque bem sucedido e mitiga a extenso do dano.
O software seguro desenvolvido de forma que possvel estabelecer que ele
continue operando corretamente em caso de ataques, resistindo explorao de falhas
no software, ou tolerando os erros e falhas que podem gerar desta explorao
(GOERTZEL, 2008).
7 QUALIDADE DE SOFTWARE
Segundo Sanders (1994), um produto de software apresenta qualidade
dependendo do grau de satisfao do cliente sob todos os aspectos do produto. Ainda
conceituando, Pressman (1995) define qualidade de software como a conformidade a
requisitos funcionais e de desempenho que foram explicitamente declarados, a padres
de desenvolvimento claramente documentados, e as caractersticas implcitas que so
esperadas de todo software desenvolvido por profissionais. Isto deixa claro que existem
duas medidas para a qualidade: a satisfao do cliente mediante os requisitos propostos
e uma viso comum padronizada que informe mtricas do que deve ser a qualidade do
software.
Existes organismos de normalizao com alta aceitao de nvel mundial que
fornecem diretrizes importantes de qualidade como ISO e CMMI.

A ISO (International Organization for Standardization) estabelece padres

relacionados ao processo de desenvolvimento de software, como a ISO/IEC 12207
referente a processos de ciclo de vida de software e a ISO/IEC 15504 PDTR referente a
avaliao de processo de software . J o CMMI (Capability Maturity Model Integration)
uma abordagem de melhoria de processos que ajuda a aperfeioar a eficcia, eficincia
e qualidade da organizao, identificando os pontos fortes e fracos alm de promover
mudanas.
Para o objeto de estudo no sero aplicados integralmente todas as mtricas
definidas pelos padres internacionais, devido ao curto prazo de entrega e a
simplicidade inicial do projeto, contudo alguns parmetros apontados foram levados em
considerao e assimilados como requisitos da aplicao. Entre eles:
Usabilidade, que um conjunto de caractersticas que vo definir a capacidade
da aplicao de ser compreendida, atrativa, legvel e navegvel;
Eficincia, caractersticas que vo definir se o servio possui boa performance,
acessibilidade e utilizao dos recursos;
Manutenibilidade, capacidade da soluo desenvolvida de ser adaptvel e
modificvel quanto a novas necessidades;
Implementabilidade, caracterstica da aplicao de ser implementvel seja
economicamente, tecnologicamente ou temporalmente em relao ao cronograma
proposto;
Funcionalidade, conjunto de particularidades que definem a capacidade da
aplicao de ter compatibilidade com outros navegadores, segurana, mecanismos de
buscas, relevncia de contedo entre outros apontadores quanto as aes executadas.
A qualidade do software fundamental para o item mais importante dentro do
desenvolvimento, a satisfao do cliente.
8 CONCLUSO
Seguindo sinteticamente os passos propostos pela Engenharia de Software, a
taxa de aceitao do software se mostrou claramente alta em relao
desenvolvimentos feitos sem utilizar uma mtrica ou um padro preestabelecido. Tais
conhecimentos dispostos e aplicados se mostraram de grande valor tanto equipe de
desenvolvimento que conseguiu desenvolver uma soluo com baixo risco, custo
reduzido, alta aplicabilidade e com um ambiente que pode ser utilizado para inmeras

outras solues, quanto aos usurios que com baixo custo de treinamento, prottipos de
exemplificao, todos requisitos desenvolvidos, melhoria e aumento de produtividade
no processo e possibilidade de novos desenvolvimentos.
Tendo em vista todos os fatores abordados, fica claro que todo o conceito
abordado pode e deve ser utilizado como mtrica para desenvolvimento das mais
diversas solues garantindo a Engenharia de Software um recurso que agrega valor
soluo proposta.
REFERNCIAS
TAFNER, Elisabeth Penzlien; DA SILVA, Everaldo. Metodologia do Trabalho
Acadmico. Indaial: ASSELVI, 2008.
ABELSON & SUTTMAN. Structure and Interpretation of Computer Programs.
MIT Press and McGraw Hill, 1985.
BRIAN CHESS & GARY MCGRAW. IEEE Security & Privacy,
November/December 2004.
CYSNEIROS, L. M. Integrando Requisitos No Funcionais ao Processo
de Desenvolvimento de Software. Rio de Janeiro. 116f. Dissertao (Mestrado
em Informtica) - Departamento de Informtica, Pontifcia Universidade
Catlica do Rio de Janeiro, 1997.
DORFMAN, M., THAYER, R. H. Standards, Guidelines and Examples of
System and Software Requirements Engineering. Los Alamitos, CA, IEEE
Computer Society Press, 1990.
GOERTZEL, B. Achieving Advanced Machine Consciousness through
Integrative, Virtually Embodied Artificial General Intelligence, 2008.
MARTIN, P.; TATE, K. Getting started in project management. New York: John
Wiley & Sons, 2001.
MORAN, T. The Command Language Grammars: a representation for
the user interface of interactive computer systems. Em International Journal of
Man-Machine Studies 15:3-50, Academic Press, 1981.
PFLEEGER, S. L. Engenharia de Software: Teoria e Prtica, Prentice Hall do
Brasil, 2 Edio, 2004
PREECE, J. Et al. Human-Computer Interaction, Addison- Wesley, 1994.
PRESSMAN, R. S. Engenharia de Software. Makron Books. So Paulo.
Brasil, 1995.
ROYCE W. WINSTON. Managing the development of large software systems,
1970.

SANDERS, Joc. Qualidade de software. 1994.

SCHILLING, M. A.; HILL, C. W. L. Managing the new product development
process: Strategic Imperatives. Academy of Management Executive, 1998.
SOMMERVILLE, Ian. Engenharia de software. So Paulo. 6. ed. Pearson
Education Companion, 2003.
Manifesto gil, Ward Cunningham. Manifesto for Agile Software Developement
Disponvel em: <http://www.agilemanifesto.org> Acesso em 01 de Junho de 2015.
Portal INPE, Instituto Nacional de Pesquisas Espaciais. Disponvel em:
<http://www2.dem.inpe.br/ijar/CriseSoftParadigmas.html> Acesso em 10 de Maio de
2015.