Escolar Documentos
Profissional Documentos
Cultura Documentos
Livro-Texto - Unidade IV
Livro-Texto - Unidade IV
Unidade IV
7 PRÁTICAS DA ENGENHARIA DE SOFTWARE
Com base na importância cada vez maior do software no dia a dia das
empresas, devemos nos preocupar com a maneira com que ele agrega valor
aos negócios das mesmas, aumentando a produtividade e diminuindo custos.
Com a finalidade de atender a esses objetivos, a área de engenharia de
software destina parte de sua atenção ao quesito qualidade na construção
de software, utilizando a definição de modelos e processos para melhoria
da qualidade e diminuição de custos no desenvolvimento e na manutenção
de sistemas. Existem hoje em dia várias propostas de modelo, buscando
melhorar o processo de desenvolvimento de software e a qualidade envolvida
(ENGHOLM JÚNIOR, 2010, p. 44).
Todos esses modelos se baseiam no conceito de melhores práticas do mercado acumuladas ao longo
de dezenas de anos. O que tem sido demonstrado é que não adiantará saber o que o produto de
software deverá fazer se não houver um ótimo time de desenvolvedores de software e a participação
ativa do usuário. Mas, também, ter pessoas qualificadas, por si só, não resolve a complexidade inerente
ao desenvolvimento de sistemas de informação. É preciso que essas pessoas trabalhem em time,
usando as melhores práticas de engenharia de software. Dentre estas, encontram-se as boas práticas
da comunicação, do planejamento de projetos, da modelagem de sistemas, das melhores soluções na
construção e das melhores práticas na colocação do produto em produção ou para implantação.
Para tratar o tema dos princípios envolvidos com as práticas de engenharia de software torna-se
necessário caracterizar o conceito de práticas:
• práticas podem ser definidas como uma coleção de conceitos, princípios, métodos e ferramentas
de que um engenheiro de software faz uso nas suas atividades do dia a dia;
• outra definição pode ser que as práticas preenchem ou determinam um modelo de processo
de software que inclui as receitas técnicas e gerenciais necessárias para fazer as tarefas do
desenvolvimento de um software.
118
ENGENHARIA DE SOFTWARE I
De acordo com Pressman (2006) e Sommerville (2007), pode-se compreender a essência da prática
das maneiras a seguir.
• Execute o plano (geração do código): diversas metodologias, técnicas e ferramentas podem ser
usadas para que o planejamento e o desenvolvimento se tornem efetivos e para que o produto de
software atinja seus objetivos. A execução do plano vai depender das escolhas que uma equipe ou
a própria organização escolher para implementá-lo. O que importa nesse momento é saber qual
é o melhor caminho a seguir, que métodos serão aplicados, as exigências legais ou dos usuários, e
que ferramentas serão úteis durante o projeto. De acordo com Souza, G. ([s.d.]), diversas questões
devem ser consideradas na execução do plano: a solução está de acordo com o plano? Cada
componente da solução está correto?
Dentre os diversos princípios centrais que os autores indicam para as práticas da engenharia de
software, podem ser citados:
• um software deve sempre fornecer valor para o cliente, o usuário final ou a área de negócio; essa
deve ser a razão para que ele exista;
119
Unidade IV
• todo projeto deve ser simples, pois a simplicidade facilita o entendimento, o uso e a evolução ao
longo do tempo; pode-se propor que os desenvolvedores mantenham o produto de software o
mais simples possível;
• é essencial manter uma visão clara do que deve ser construído; clareza indica uma forma fácil de
todos os envolvidos entenderem da mesma maneira o que deve ser feito;
• os produtos de software têm como característica serem consumidos por todos os tipos de usuários,
tanto com relação ao conhecimento quanto com relação à quantidade; daí a importância de o
produto ser especificado, projetado e implementado sabendo-se que outras pessoas terão de
entender o que foi feito, para poder dar continuidade ao longo da evolução deste;
• todo gestor de projetos de software tem de planejar com antecedência as possibilidade de reusar
códigos ou soluções já existentes, já que o reúso permite a redução de custo do projeto e a
qualidade;
Saiba mais
120
ENGENHARIA DE SOFTWARE I
Sobre a comunicação, outros conceitos a associam como forma que procura a fluidez de mensagens
entre os membros de uma organização, assim como entre esta e seu meio, afetando opiniões, atitudes
e condutas, tanto para os receptores internos quanto para os externos, a fim de poder alcançar, com
a maior eficácia, seus objetivos, baseando-se na investigação para conseguir as oportunidades nas
diferentes áreas, em razão do conhecimento das problemáticas e de distintas necessidades. Já num
nível gerencial, a comunicação determina a eficiência tanto para a solução de problemas quanto para o
fortalecimento das relações entre aqueles que a conformam, estruturando, dessa forma, o planejamento
e o controle.
Com relação aos princípios da comunicação, os autores definem dez, que podem ser descritos
da seguinte forma: escute; prepare-se antes de se comunicar; alguém deve facilitar a atividade;
comunicação face a face é melhor; faça anotações e documente as decisões; busque colaboração;
conserve-se focado; se algo não estiver claro, desenhe uma figura; quando concordar com algo ou não,
prossiga; e negociação não é um concurso ou jogo.
• segundo princípio – prepare-se antes de se comunicar: gaste tempo para entender o problema e,
se necessário, pesquise para entender o jargão do negócio;
• terceiro princípio – alguém deve facilitar a atividade: toda reunião deve ter um facilitador para
conduzir a conversa, a fim de que seja sempre produtiva, bem como para que possa mediar
possíveis conflitos e garantir que os outros princípios sejam seguidos;
• quarto princípio – comunicação face a face: considerada a melhor forma de comunicação, mas
o uso de outra forma é sempre bem-vinda; por exemplo, o uso de documentos ou desenhos,
gráficos ou diagramas também é aceito como forma efetiva de comunicação;
• quinto princípio – faça anotações e documente as decisões: alguém que participe da comunicação
deve anotar todos os pontos e decisões importantes;
• sexto princípio – busque colaboração: é importante que os outros membros da equipe façam
colaborações, mesmo que sejam pequenas, pois estas aumentam a confiança entre os membros;
121
Unidade IV
• oitavo princípio – caso algo não esteja claro, desenhe uma figura: quando a comunicação por
palavras não conseguir esclarecer, normalmente, um desenho o fará;
• nono princípio – quando concordar com algo, ou não, prossiga: fazer isso, às vezes, é a melhor
forma de conseguir agilidade na comunicação;
Com relação à comunicação nas organizações (um dos focos dos sistemas de software), Kunsck
(2003) afirma que a comunicação-ação é o efeito ou o meio de comunicar-se; ato ou efeito de
emitir, transmitir e receber mensagens por meio de métodos e/ou processos, quer por meio da
linguagem falada ou escrita, quer por outros sinais ou aparelhamento técnico especializado, sonoro
e/ou visual.
Saiba mais
122
ENGENHARIA DE SOFTWARE I
Interação
face a face
Interação
somente de voz
Interação escrita
Multimídia não
interativa
Escrita não
interativa
Formas de comunicação
Uma análise da figura mostra que a mais efetiva forma de comunicação entre as pessoas, apontada
pelas pesquisas na área de desenvolvimento de sistemas, é a interação face a face, e que quanto mais as
formas são escritas, pior fica a comunicação efetiva da pessoas. Esse é um dos grandes argumentos dos
métodos ágeis em prol de menos documentos e mais interação dos times de desenvolvimento. Todavia,
como já foi mostrado, os extremos não são bons.
Em muitos casos, não é possível ficar sem as descrições ou os documentos formais exigidos tanto
pelos clientes quanto pelas legislação em vigor. Revisando-se os dez princípios da comunicação, vê-se,
no quinto princípio, a necessidade de anotações nas comunicações, e, no oitavo princípio, o uso de
desenhos ou diagramas para garantir o entendimento da comunicação entre seus participantes.
Essa técnica de reunião pode ser aplicada em diversos momentos do desenvolvimento de software e
a diversas atividades do processo, tanto no levantamento de informações junto aos clientes e usuários
quanto nas revisões técnicas de produtos de software e, também, na aprovação do cliente aos produtos
construídos etc.
A técnica walkthrough pode ser considerada como mais informal do que um Joint Application
Development (JAD) ou uma reunião de inspeção. Essa técnica foi detalhada na norma IEEE 1028 (2008).
123
Unidade IV
Em geral, a norma apresenta uma explicação passo a passo e tem dois grandes objetivos: obter
feedback sobre a qualidade técnica ou o conteúdo de um documento e/ou familiarizar o público presente
com o conteúdo. Um passo a passo é normalmente organizado e dirigido pelo autor do documento
técnico. Qualquer combinação de pessoal interessado ou tecnicamente qualificado (de dentro ou de fora
do projeto) pode ser incluída conforme parecer adequado.
• o líder do walkthrough, que conduz a reunião passo a passo, lida com tarefas administrativas e
garante a realização ordeira dessa reunião (muitas vezes, é o próprio autor que faz esse papel);
• o escriba, que observa todas as anomalias (defeitos potenciais), as decisões e todos os itens de
ação identificados durante as reuniões de passo a passo.
Já Yourdon e Argila (1998) afirma que walkthrough é uma revisão, por pares ou em grupo, de
qualquer produto técnico em um processo de desenvolvimento de software. O autor argumenta que essa
revisão pode incluir tanto outros engenheiros de software quanto usuários, programadores, analistas,
projetistas e operadores que possam estar envolvidos nos vários aspectos de um software.
Observação
Tradicionalmente, a técnica de reunião JAD tem sido utilizada por profissionais de desenvolvimento
de sistemas e usuários para a descoberta e a definição de requisitos de sistemas. Tem sido adotada
124
ENGENHARIA DE SOFTWARE I
também por todos os que desejam trabalhar em projetos, sejam da área de informática ou não, ou que
queiram tomar decisões que afetem múltiplas áreas da organização, buscando tratar os usuários-chave
como coautores do trabalho, transformando-os em clientes integrados ao projeto.
Práticas de uma reunião JAD que leva aos objetivos traçados (WOOD; SILVER, 1995):
• todos sabem para que estão ali; as reuniões são marcadas com antecedência, e todos são
comunicados;
• as pessoas presentes não têm compromissos paralelos; as reuniões exigem total dedicação dos
participantes, e as entradas e saídas não são permitidas, nem atendimentos de problemas fora da
reunião;
• as pessoas presentes estão envolvidas com os assuntos que são objeto da reunião; todos são
interessados e participam a fim de resolver algum tipo de problema ou propor soluções para ele;
• há um responsável pela condução da reunião (líder); este deve ser experiente em conduzir reuniões
objetivas;
• há horário preestabelecido para início e término; os horários são fundamentais para o sucesso da
reunião;
• as sessões da reunião duram de 90 a 120 minutos; podem existir JADs que duram mais de um dia;
isso vai depender do assunto, do número de participantes e da pauta predefinida;
• há intervalos para café de 5 a 15 minutos; são importantes paradas programadas, para que as
pessoas possam decidir assuntos particulares e para outras necessidades pessoais;
125
Unidade IV
Diversas outras formalidades devem ocorrer a fim de que a reunião seja efetiva e de que se proporcione
um ambiente ideal para a integração:
• sala de reuniões: a preocupação com a escolha do local deve ser um item de planejamento
importante; deve ser escolhido um local “isento de influências”;
• quadro branco: utilizado para rascunhar modelos, sequência de atividades, segmentação de papéis
e quaisquer outros recursos que facilitem a compreensão do tema exposto;
• flip-chart: utilizado para oficializar (formalizar, publicar) as principais decisões do grupo; deve ser
lembrado que as anotações de cada um são de uso particular;
• como são várias cabeças interpretando uma situação fictícia, cada um tem uma forma de vê-la;
visualizá-la em um único formato auxilia no entendimento (uso de padrões de documentação);
• paredes: tudo o que for publicável (charts) deve ficar afixado na sala de reuniões durante todo o
tempo que durar o levantamento;
• o pessoal de limpeza deve ser avisado de que esse material deve permanecer afixado de
um dia para o outro (se a duração da reunião ultrapassar um dia); esse material é fator
extremamente produtivo, principalmente, quando se necessita resgatar algum ponto já
discutido e acordado; a estratégia é escrever no flip-chart, destacá-lo e afixá-lo em seguida;
deve-se ter cuidado com o excesso de poluição visual, pois os participantes não conseguem
se concentrar nas discussões;
• mesa grande ou montagem em U: o objetivo é que todos estejam o mais próximos e visíveis
possível; vale lembrar que, antes de tudo, uma reunião é um encontro de pessoas – e pessoas
próximas fomentam o comprometimento;
• ambiente confortável: boa iluminação, ventilação adequada e baixo nível de ruído são pontos
importantes para aumentar a produtividade dos trabalhos.
A convocação dos participantes deve ser antecipada. Cada um deve receber a convocação junto à
agenda de reunião da qual está sendo solicitado a participar. A agenda deve ser produzida com base no
enfoque do levantamento – overview, macro, detalhe etc.; deve também considerar todos os tópicos
que serão abordados durante as sessões da reunião – passos, necessidades, modelos, problemas etc.
Cada sessão deve ter horário de início, duração, intervalos e fim preestabelecidos. Na convocação
com antecedência devem constar:
• os objetivos da reunião;
126
ENGENHARIA DE SOFTWARE I
• Abertura: é quando são feitas as apresentações dos participantes. Essa poderá ser a primeira
oportunidade para que os usuários e analistas venham a se encontrar. Caso seja a primeira
reunião do grupo, esse momento é oportuno para apresentar os participantes e a metodologia da
reunião, assim como definir a conduta do grupo. Depois das apresentações, devem-se estabelecer
os horários de desenvolvimento da reunião, e a agenda deve ser apresentada.
• Desenvolvimento: nessa parte, ocorre o levantamento das informações propriamente dito. Cada
tópico da agenda deve ser detalhado, sempre um por vez. Não se parte para o próximo tópico
sem se ter esclarecido tudo a respeito do anterior. Aqui estão incluídas, também, as aprovações
necessárias.
• Fechamento: não é o fim da reunião; deve-se começar essa parte com tempo suficiente para se
atingir o horário de fim preestabelecido na agenda. É quando são feitos os resumos do que se
discutiu e se aprovou. Se algo tiver ficado pendente, é nesse ponto que deverá ser esclarecido.
Nesse momento também se distribuem tarefas para as próximas reuniões e se estabelecem suas
futuras datas (se for o caso).
Saiba mais
Esta figura apresenta uma visão de esforços e sinergia em projetos de qualquer natureza.
Essa pergunta será respondida a partir dos conceitos e definições apresentados no Guia PMBOK
(Project Management Body of Knowledge) ou conjunto de conhecimentos em gerenciamento de
projetos, do Project Management Institute PMI (2008):
128
ENGENHARIA DE SOFTWARE I
Ainda de acordo com o PMBOK (2008), cada projeto cria um produto, serviço ou resultado exclusivo.
Embora elementos repetitivos possam estar presentes em algumas entregas do projeto, essa repetição
não muda a singularidade fundamental do trabalho do projeto. Por exemplo, prédios de escritórios são
construídos com materiais idênticos ou similares, ou pela mesma equipe, mas cada um é exclusivo –
com diferentes projetos, circunstâncias, fornecedores etc.
Processos de
monitoramento e controle
Processos de
planejamento
Processo de Processo de
iniciação encerramento
Processos de
execução
Aprofundando-se no guia PMBOK do PMI (2008), esse modelo considera que o gerenciamento de
projetos é realizado pela execução de processos que podem ser agrupados em: iniciação; planejamento;
execução; monitoramento e controle; e encerramento. Esses processos são executados de forma inter-
relacionada, e a gestão do projeto abrange todos os outros processos, inclusive, o de planejamento, que
é apresentado no guia como processos de monitoramento e controle.
129
Unidade IV
De acordo com o guia PMBOK (2008), o planejamento envolve um grupo de processos realizados
para estabelecer o escopo total do esforço, definir e refinar os objetivos e desenvolver o curso de ação
necessário para alcançar esses objetivos. O processo de planejamento abrange o plano de gerenciamento,
ou plano do projeto, bem como os documentos que serão usados para executá-lo.
No caso do projeto, o cenário favorável para um gerente de projetos pode ser descrito em termos
de cliente satisfeito com o resultado do projeto, prazo cumprido e teto orçamentário não ultrapassado.
Numa empresa estruturada por projetos (por exemplo, uma instituição de pesquisa ou uma firma de
consultoria), pode-se falar de planejamento em distintos níveis: planejamento estratégico da própria
empresa; planejamento agregado dos projetos; planejamento das áreas de apoio aos projetos; e o
planejamento de cada projeto em si.
A seguir, serão detalhadas diversas práticas envolvidas no planejamento de projetos, que serão
baseadas no Guia PMBOK de 2008 e no livro Gerenciamento de Projetos, de 2000, (PMBOK, 2008;
GASNIER, 2000).
Para um planejamento eficaz de projetos, conforme o guia PMBOK e conforme intensamente utilizado
em projetos de software, propõem-se algumas práticas clássicas que podem ser organizadas da seguinte
forma: plano de projetos, estrutura analítica do projeto, recursos, cronogramas e gerenciamento de
riscos.
O plano de projetos reúne toda a documentação gerada durante o ciclo de vida do projeto,
de forma que as ideias, os cálculos, as análises, as avaliações, as conclusões e os compromissos
sejam registrados e comunicados aos envolvidos, assegurando disciplina e sistematização dos
130
ENGENHARIA DE SOFTWARE I
processos. Todos os processos geram documentos que são arquivados na respectiva pasta, manual
ou automatizada, mas é no processo de planejamento que o plano começa a ser efetivamente
detalhado.
De acordo com os guias práticos em gerenciamento de projetos (PMBOK, 2008; GASNIER, 2000),
um plano de projeto deverá incluir itens que deixem claros os objetivos e as responsabilidades
envolvidas no projeto, que podem ser agrupados da seguinte forma: objetivos do projeto; premissas,
obstáculos, estratégias, análise de viabilidade; escopo do projeto; recursos envolvidos; responsabilidades;
cronogramas; gerenciamento de riscos; orçamento; prontuário do projeto; e outros documentos
gerenciais envolvidos.
De acordo com o guia PMBOK (2008), para se criar a estrutura analítica do projeto (EAP), torna-se
necessário realizar as seguintes atividades ou passos: desenhar a estrutura analítica; criar um dicionário
da EAP; criar uma linha de base do escopo (baseline); e atualizar os documentos do projeto.
Para Gasnier (2000), a EAP é uma aplicação prática do princípio analítico de Descartes: decomponha
um problema complexo em pequenos problemas mais simples, fáceis de serem resolvidos; então,
administre os pequenos problemas progressivamente em direção à solução do todo; finalmente, sintetize
(recomponha) o conjunto com uma integração lógica.
Servindo ao propósito de comunicar tudo o que deve ser realizado desde o início até a conclusão
do projeto, a EAP pode ser representada de forma esquemática ou por meio de uma lista de atividades
indentadas, similar à estrutura de diretórios de arquivos utilizada em computadores e sistemas
operacionais.
Cada uma dessas atividades, perfeitamente definidas, constituirá um pacote de serviços, no original,
work control package, individualmente controlável.
131
Unidade IV
A figura apresenta um exemplo de EAP. O modelo representa a visão da implantação de uma escola,
com somente algumas opções preenchidas.
Terreno
Estrutura
Energia elétrica
Projetos
Hidráulica
Compra
Edifício principal Sistemas Iluminação
Instalação
Som
Implantação da Inspeção/testes
escola Climatização
Equipamentos
Auditório
Programa acadêmico
Operação e
manutenção
Administração do
projeto
A alteração da EAP, uma vez necessária, deverá ser feita com os mesmos cuidados da versão original
(inclusive no que se refere à divulgação geral).
7.4.3 Recursos
Para o planejamento de projetos, denomina-se recurso qualquer variável capaz de definir aquilo
que será necessariamente requerido para a execução de uma atividade que possa, de alguma forma,
restringir o progresso do projeto.
Alguns tipos de recursos são: pessoas, equipamentos, materiais, capital, instalações etc. Todavia,
não necessariamente todos os recursos devem ser registrados nos documentos ou softwares de
agendamento, mas apenas aqueles que preenchem determinados requisitos, como qualquer recurso
132
ENGENHARIA DE SOFTWARE I
que possa restringir, impedir ou atrasar o progresso de uma tarefa e qualquer recurso que tenha um
custo associado à sua utilização ou ao consumo.
• levantamento das necessidades: cada atividade deve ser avaliada quanto à sua identificação, no
que se refere aos recursos necessários e suficientes, quantificando-se o esforço requerido em
dedicação para executá-la;
• julgamento de especialistas: pessoas com experiências anteriores podem contribuir para o projeto,
procurando validar e ajustar as necessidades apuradas;
• tomada de decisão: escolha da melhor alternativa no que se refere à sua composição nos requisitos
de qualidade, prazo e custo, objetivando o sucesso do projeto.
7.4.4 Responsabilidades
A atribuição de responsabilidades é outra ferramenta importante que visa formalizar quem (pessoa ou
departamento) será responsável por quais etapas ou atividades do projeto. A distribuição dos trabalhos é
um processo de negociação pelo qual o gerente do projeto obtém o comprometimento das pessoas para
a realização das atividades do projeto. As ferramentas de automação de agendamento de programação
permitem registrar as responsabilidades nas atividades do projeto. Normalmente, são determinadas nas
reuniões de kick-off do projeto, e as assinaturas são tomadas nas atas da reunião.
De acordo com Gasnier (2000), o organograma linear é uma das maneiras de se organizar e
documentar as responsabilidades de cada pessoa envolvida em relação a cada processo de um ou mais
projetos.
133
Unidade IV
7.4.5 Cronogramas
Marcos são eventos com duração nula, servindo como referência, meta ou pontos de controle
(checkpoints) com relação ao progresso do projeto.
Risco é o efeito acumulado das chances de ocorrências incertas que vão afetar negativamente os
objetivos do projeto; está relacionado com o grau de exposição do projeto a eventos negativos e suas
prováveis consequências, sempre se tratando de uma ocorrência futura.
A incerteza representa uma oportunidade de ganhar ou perder. Assim, é fundamental que os gerentes
de projetos e seus patrocinadores compreendam que projetos são exercícios de riscos.
134
ENGENHARIA DE SOFTWARE I
De acordo com Gasnier (2000), outro aspecto interessante de se ressaltar é que o risco depende do
prazo de que se dispõe para lidar com a sua causa. O autor ressalva que a avaliação dos riscos pode
ser realizada na transição de cada etapa do projeto, mas, principalmente, deve ser observada logo ao
final do processo de planejamento, antes do início efetivo da execução, pois, nessa ocasião, já se tem
quantidade de informações suficiente, e a maior parte dos recursos ainda não foi comprometida.
Existem diversas técnicas ou práticas para a identificação dos riscos de um projeto, dentre as quais
se destacam:
• checklists montados a partir das lições aprendidas de projetos anteriores que funcionam como
instrumentos para prevenir a repetição das causas dos riscos identificadas;
• aplicação da análise de modos e falhas e efeitos (FMEA), que podem contribuir muito para o
processo de gerenciamento de riscos, desde a identificação do evento;
Após a identificação dos riscos do projeto, estes precisam ser quantificados, visando a compreender,
com mais detalhes, suas implicações e, a partir daí, estar mais bem-preparado para decidir como tratar
esses riscos. A abordagem mais utilizada para isso é a análise do impacto e da probabilidade.
8 PRÁTICAS DE MODELAGEM
Existe uma crença, entre os que trabalham com desenvolvimento de software, de que, de alguma
maneira, a modelagem pode ser aplicada para facilitar essa atividade. Todavia, ao longo do tempo,
a prática da modelagem de software vem sendo criticada, em virtude da percepção de que é uma
atividade que precede o desenvolvimento real e que tem como foco a documentação.
Outros autores insistem que a modelagem deve ser reconhecida como uma tarefa de desenvolvimento
central importante, e não como uma atividade enfocada principalmente em documentação. Quando
os modelos são considerados artefatos de desenvolvimento de primeira classe, os desenvolvedores
geram menos código convencional, uma vez que abstrações de aplicativo mais poderosas podem ser
empregadas.
135
Unidade IV
Assim, o desenvolvimento dirigido por modelo é inerentemente mais produtivo e ágil. Além disso, outros
participantes no desenvolvimento, como analistas de negócios, arquitetos e gerentes de projetos, reconhecerão
a modelagem como um adicional de valor às tarefas pelas quais são responsáveis.
Saiba mais
Ainda de acordo com a Microsoft (2005), um modelo deve ser um artefato de primeira classe em um
projeto, e não apenas uma documentação aguardando para se tornar desatualizada.
O autor Senge (1990) define que modelos são mentais e que são pressupostos profundamente
arraigados, generalizações ou mesmo imagens que influenciam a forma de ver o mundo e de nele
agir. Muitas vezes, não estamos conscientes de nossos modelos mentais ou de seus efeitos sobre
nosso comportamento. O trabalho com esses modelos inclui, também, a capacidade de realizar
conversas ricas em aprendizados, que equilibrem indagação e argumentação, em que as pessoas
exponham de forma eficaz seus próprios pensamentos e estejam abertas à influência dos outros.
Os modelos possuem uma sintaxe precisa, geralmente são mais bem-editados e mais bem-
visualizados com uma ferramenta gráfica e contêm semânticas que determinam como conceitos
específicos de domínio mapeiam para outros artefatos de implementação, como código, estruturas
de projeto e arquivos de configuração. Dessa maneira, um modelo se parece muito com um arquivo
de código-fonte, e os mecanismos que o sincronizam com outros artefatos de implementação são
muito semelhantes a compiladores. Um modelo representa um conjunto de abstrações que dá
suporte a um desenvolvedor, num aspecto de desenvolvimento bem-definido. Como os modelos
podem abstrair e agregar informações de uma série de artefatos, podem dar suporte de modo
mais rápido a verificações de consistência e outras formas de análise.
136
ENGENHARIA DE SOFTWARE I
Observação
Um modelo de conectividade de aplicativos poderá dar suporte à
validação de protocolo de contrato, análise de segurança ou análise de
desempenho.
• um meio para discussão: o modelo de processos ajuda a situar as questões relevantes ao permitir
a abstração do mundo real, salientando os objetos e relacionamentos que são de interesse,
ignorando detalhes que possam contribuir para aumentar a complexidade;
• um meio para comunicação: permite que outras pessoas, que não as implicadas no desenvolvimento do
modelo, possam utilizá-lo como base para a sua implementação ou para a concepção de novos modelos;
• uma base para análise: a análise de um modelo pode revelar os pontos fortes e os pontos fracos
do processo, com especial relevância para os fracos, como ações que acrescentam pouco valor ou
são potenciais focos de problemas;
• a análise por simulação e animação do modelo permite, ainda, estudar os efeitos que possíveis
alterações podem causar em um dado processo;
• uma base para concepção de novos processos;
• uma base para melhoria contínua: as sugestões para a mudança podem ser expressas em alterações
ao modelo e sua análise, sendo possível, ainda, sugerir métricas para avaliar o seu desempenho;
• uma base para controle: quando suficientemente formal, para ser automatizado, o modelo pode
ser utilizado para controlar a execução do sistema modelado, como em um sistema de gestão de
workflow.
• além de garantir o correto funcionamento, permite efetuar medições quanto ao desempenho do
processo.
Frequentemente, a modelagem usa algum tipo de notação gráfica e é apoiada pelo uso de
ferramentas de apoio denominadas de Computer-Aided Software Engineering (CASE). Ferramentas
CASE correspondem a uma classificação que abrange todas as ferramentas baseadas em computadores
que auxiliam em atividades de engenharia de software, desde análise de requisitos e modelagem até
programação e testes; podem ser consideradas como ferramentas automatizadas que têm como objetivo
auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.
Saiba mais
A seguir serão detalhadas diversas práticas fundamentais e envolvidas com a modelagem de sistemas
de informação, as denominadas práticas de modelagem.
De acordo com Pressman (2006) e Sommerville (2007), há muito tempo se busca um padrão de
construção de software orientado a objetos e sua representação à semelhança da planta utilizada por
outras áreas da engenharia, tal como a planta de uma casa ou a arquitetura de um prédio da engenharia
civil.
O enfoque tradicional de modelagem para a construção de sistemas de informação é baseado na
compreensão desse sistema como um conjunto de programas, que, por sua vez, executam processos
sobre dados.
138
ENGENHARIA DE SOFTWARE I
O enfoque de modelagem por objetos vê o mundo como uma coletânea de objetos que interagem
e apresentam características próprias, que são representadas pelos seus atributos (dados) e operações
(processos) (FURLAN, 1998).
A próxima figura mostra o enfoque baseado em sistema versus o enfoque baseado em objetos.
Programa Classe
Processos
Atributos
Dados
Operações
Carros, equipamentos, pessoas, bancos etc. apresentam características próprias que podem ser
representadas por seus atributos e seus comportamentos no mundo real.
Furlan (1998) informa que essa abordagem oferece como principais benefícios:
• manter a modelagem do sistema e sua automação o mais próximos possível de uma visão
conceitual do mundo real;
• servir de base à decomposição e modelagem do sistema nos dados, que é o elemento mais estável
de todos aqueles que compõem um sistema de informação;
• oferecer maior transparência na passagem de modelagem para construção por meio da introdução
de detalhes, não requerendo uma reorganização do modelo.
Lembrete
Embora a expressão orientação a objetos tenha sido usada de formas
distintas, deveria sugerir uma associação entre coisas do mundo real e
trechos de programas de computador ou objetos.
139
Unidade IV
Uma nova maneira de pensar os problemas, utilizando modelos organizados, a partir de conceitos do
mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma
única entidade (JACOBSON; BOOCH; RUMBAUGH, 1999).
De acordo com Yourdon e Argila (1998), o modelo de análise orientada a objetos (AOO) serve para
dois propósitos:
• estabelecer a maneira pela qual um dado conjunto de objetos colabora para executar o trabalho
do sistema de software que está sendo especificado.
Na AOO de Yourdon e Argila (1998), existem cinco camadas ou visões, conforme a figura a seguir,
que permitem visualizá-la de perspectivas distintas.
Borda da classe
Classes e objetos
Borda da instância (objeto)
Atributos
Atributos
Conexão entre
objetos
Mensagens
Serviços
Serviços
Estruturas
Assuntos Assunto
140
ENGENHARIA DE SOFTWARE I
No caso de métodos orientados a objetos, tem sido dada mais ênfase à modelagem de informações
como um procedimento formal no processo de engenharia de software (YOURDON; ARGILA, 1998).
A figura a seguir apresenta um exemplo de aplicação da modelagem AOO com o uso da notação de
Edward Yourdon. Serão representadas as entidades envolvidas em um domínio de prestação de serviços
por assinatura, por exemplo, uma assinatura de TV fechada, uma assinatura telefônica etc.
Assinante Assinatura
Id_assinante Id_assinatura
Det_assinante 1 1 Estado_assinatura
Id_endereço Detalhes_assinatura
Entrar_assinante Entrar_assinatura
Informar_endereço Renovar_assinatura
Após a modelagem completa do sistema, com todas as entidades, seus atributos, seus serviços e
suas estruturas comportamentais definidas (relacionamentos), deve ser construído o projeto orientado
a objetos (POO) como uma extensão do modelo AOO, e, a partir dos modelos do POO, são construídos
os códigos das transações.
Na proposta de Edward Yourdon, o modelo POO contém as mesmas cinco camadas e usa
a mesma notação do modelo AOO, mas é estendido para conter: componente de interação
humana (interface homem-máquina), componente de gerenciamento de tarefas e componente
de gerenciamento de dados.
O componente de interação humana modela a tecnologia de interface que será usada para uma
implementação específica do sistema. O componente de gerenciamento de tarefas especifica os
itens operacionais que serão estabelecidos para implementar o sistema. Por fim, o componente de
gerenciamento de dados define aqueles objetos necessários para fazer interface com a tecnologia de
banco de dados que está sendo usada.
141
Unidade IV
• Sally Shlaer e Stephen Mellor escreveram livros sobre análise e desenho orientado a objetos no
final da década de 1980 e início da década de 1990;
• Jim Odell e James Martin basearam seus enfoques na longa experiência adquirida por ambos
no uso e na divulgação da engenharia da informação; em 1994 e 1996, lançaram os livros mais
conceituais da época;
• Peter Coad e Edward Yourdon escreveram livros que propuseram um enfoque de desenho recursivo
em 1997, propondo a AOO e o POO;
• James Rumbaugh liderou uma equipe de pesquisadores nos laboratórios da General Electric, o que
levou ao livro sobre métodos chamados Object Modeling Technique (OMT), em 1991;
• Grady Booch desenvolveu um método na Rational Software para análise de sistemas intensivos
em engenharia que foram apresentados em seus livros publicados em 1994 e 1995;
• Ivar Jacobson produziu seus livros a partir de sua experiência em sistemas na Ericsson e desenvolveu
o método Object-Oriented Software Engineering (OOSE), que se tornou a base do processo UP e
do processo RUP.
Saiba mais
142
ENGENHARIA DE SOFTWARE I
Ivar Jacobson, Grady Booch e James Rumbaugh, em 1995, tiveram a iniciativa de unificar os métodos
OOSE, o método Booch’93 e o método Object Modeling Technique (OMT) e deram ao resultado dessa
unificação o nome de Unified Modeling Language (UML), uma ferramenta para modelagem de sistemas
de todas as complexidades (MEDEIROS, 2004).
Em 1999, na versão 1.3, a UML passou a ser mantida pela Object Management Group (OMG), que
é um grupo americano responsável pela padronização do uso da orientação a objetos nos Estados
Unidos. A UML firma-se, então, no mercado e passa a ser um padrão internacional para especificação e
modelagem de sistemas aplicativos em todas as áreas de abrangência, de informática ou TI.
A UML foi criada para ser independente de processo de software. Os desenvolvedores podem adotar
da UML algo que seja apropriado ao seu projeto e ao seu processo, usando-a para registrar os resultados
de suas decisões de análise e design.
Para garantir ser um padrão internacional, a UML foi adotada pela OMG, que especifica e mantém o
metamodelo UML. A especificação, na OMG, é definida usando-se uma abordagem de metamodelo, isto
é, este é usado para especificar o modelo que compreende a UML, que adota técnicas de especificação
formal. A UML não é um modelo de processo/metodologia de software, mas sim uma notação, um
mecanismo para “mostrar o problema”, de forma que exponha a essência do domínio de um aplicativo.
A combinação da UML com um bom processo, como o RUP ou o Scrum, resulta em uma poderosa
combinação para a criação de aplicativos bem-sucedidos (REED JÚNIOR, 2000).
A linguagem de modelos UML tem dois objetivos: proporcionar consistência informando o cliente
ou patrocinador do projeto de que o domínio do problema está bem-entendido pela equipe de
desenvolvedores; e proporcionar um modelo de consistência para a equipe de implementação (arquitetos
e programadores), que, assim, poderá implementar adequadamente o software.
Lembrete
Deve ficar claro que somente os diagramas apresentados na UML não são
suficientes para garantir o processo de desenvolvimento. Outros elementos,
como um plano de projeto e profissionais preparados, são fundamentais
para que o projeto não falhe.
A UML propõe 13 diagramas que estão divididos em três categorias: estático, dinâmico e arquitetural.
dinâmica das coisas, mas simplesmente sua organização. Os três principais diagramas estáticos da
UML são: modelo de caso de uso; modelo de classes; e modelo de objetos.
• Os diagramas dinâmicos mostram a interação ativa que o sistema suporta; detalham a interação
dos elementos estruturais dos diagramas estáticos. Essas interações dinâmicas são descobertas,
nos casos de uso, como caminhos executados em resposta a alguns estímulos externos ao sistema.
Os diagramas dinâmicos mostram o comportamento pretendido do sistema. Os principais são:
atividades, comunicação, sequência e estado.
1 Atividade Atividade
4 Objetos Objetos
5 Sequência Sequência
6 Colaboração Comunicação
Diagramas
7 Estado Estado
8 Componentes Componentes
10 ------------- Pacotes
11 ------------- Interação
12 ----------- Tempo
Cada diagrama da UML ou modelo pode ser usado em um determinado momento do ciclo de
desenvolvimento de software. Deve ser utilizado para resolver ou mostrar aspectos específicos
do problema sendo modelado, ou, ainda, para especificar artefatos diversos em atividades
diferentes do processo de software. Por exemplo, o diagrama de atividade pode ser usado para
detalhar uma funcionalidade, como mostrar um determinado fluxo do problema que está sendo
estudado etc.
144
ENGENHARIA DE SOFTWARE I
Na figura, vemos um exemplo de aplicação do diagrama de classes de objetos da UML 2.3. Desse
diagrama, podem ser derivadas as estruturas do banco de dados e as classes de objetos programadas.
Gerência 0..*
Trabalha para
Salário
Gerência Cargo
A notação BPMN surgiu como um padrão alternativo à linguagem UML com relação à modelagem
dos processos de negócio – também sendo gráfica –, porém seus símbolos são um pouco diferentes,
pois a BPMN foi criada especificamente para modelar processos de negócio. Essa notação não oferece
nenhum suporte para modelar dados, atores, estados de ciclo de vida ou sistemas.
A notação BPMN foi desenvolvida pela Business Process Management Initiative (BPMI), iniciativa
oriunda da OMG (2011), que lançou a especificação 1.0 ao público, em maio de 2004. Tanto a UML
quanto a BPMN são notações mantidas pela OMG (2011).
• fornecer uma notação que seja facilmente entendida pelos analistas de negócios;
A BPMN define um Business Process Diagram (BPD), que é baseado em um fluxograma adaptado
para a criação de modelos gráficos de tarefas dos processos de negócio. Para ela, um modelo de processo
de negócios é uma rede de objetos gráficos, denominados de atividades, e do fluxo de controle que
define a ordem de execução.
145
Unidade IV
Um BPD é formado por um conjunto com quatro elementos gráficos, que são:
Um exemplo de BPD simples, em que a maioria dos objetos da BPMN é utilizada, pode ser visualizado
na figura a seguir.
class SPMM
Um conceito de modelagem é o Model Driven Development (MDD), que surgiu com o objetivo de
ajudar a resolver os problemas ainda vigentes com os modelos e as práticas atuais, principalmente, os
do tipo UML, que são aplicados nos ciclos clássicos e interativos de desenvolvimento de software.
146
ENGENHARIA DE SOFTWARE I
• fazer que o engenheiro de software não precise interagir manualmente com todo o código-fonte,
podendo se concentrar em modelos de mais alto nível, ficando protegido das complexidades
requeridas para implementação nas diferentes plataformas;
• um mecanismo automático é responsável por gerar o código, a partir dos modelos; nesse cenário,
modelos não são apenas um guia ou uma referência, mas fazem parte do software, assim como o
código-fonte;
• automatizar as transformações não é uma tarefa simples; a figura mostra os principais elementos
necessários para essa abordagem e como eles são combinados;
Outros
modelos
Modelo
Mecanismo para
executar transformações
Transformação Código-fonte
Ferramenta
para definir
transformações
• para possibilitar a criação de modelos, é necessária uma ferramenta de modelagem; utilizando essa
ferramenta, o engenheiro de software produz modelos que descrevem os conceitos do domínio;
• para isso, a ferramenta deve ser intuitiva e de fácil utilização, e, ao mesmo tempo, os modelos
por ela criados precisam ser semanticamente completos e corretos, uma vez que devem poder
ser compreendidos por um computador (e não por um ser humano) capaz de corrigir pequenos
enganos ou de preencher lacunas por si só;
• o elemento que implementa essas características é normalmente uma linguagem específica de
domínio, ou Domain-Specific Language (DSL);
• os modelos servem de entrada para transformações que irão gerar outros modelos ou o código-
fonte;
• para definir as transformações, é necessária uma ferramenta que permita ao engenheiro de
software construir regras de mapeamento de modelo para modelo, ou de modelo para código;
• idealmente, essa ferramenta deve possibilitar que as regras de mapeamento sejam construídas da
forma mais natural possível, uma vez que a construção de transformadores é uma tarefa complexa;
147
Unidade IV
Saiba mais
Outros modelos praticados que podem ser citados são os de Carvalho e Chiossi (2001):
• o modelo funcional é uma forma de decompor o sistema a ser desenvolvido por meio de suas
principais funções e subfunções conectadas; cada conexão representa um duto por onde fluem
os dados que serão recebidos, tratados, armazenados e enviados a outras funções, ou devolvidos
para o mundo externo do sistema;
• o modelo de dados representa os que deverão ser armazenados e acessados pelo sistema, o
relacionamento entre os grupos de dados e como estes serão utilizados;
• os modelos formais utilizam notações matemáticas para especificar sistemas e podem ser
empregados em qualquer estágio da especificação de um sistema;
• os modelos para testes de programas visam representar os softwares abstraindo apenas o que for
de interesse para a fase de teste. Esses modelos são bastante utilizados nas fases de teste unitário
e de teste de integração.
Diversas boas práticas são recomendadas pelos modelos de desenvolvimento, tais como o UP, o RUP
e os modelos de qualidade, como o CMMI-DEV, o MPS.BR, as normas ISO etc. Dentre essas práticas,
encontram-se o desenvolvimento iterativo (já abordado), a gerência de requisitos, a arquitetura baseada
em componentes, a modelagem visual, a verificação de qualidade, o controle de mudanças, os testes
durante o ciclo de desenvolvimento, o uso de práticas ágeis etc.
148
ENGENHARIA DE SOFTWARE I
A arquitetura de um software abrange a definição dos elementos estruturais, bem como suas inter-
relações e seus comportamentos.
• deverá ser flexível, para facilitar a manutenção e a extensibilidade do software ao longo do seu
ciclo de vida;
• baseada em componentes, para se ter os módulos o mais independentes possível e que possam
ser reutilizados.
Devem-se usar modelos visuais ou a modelagem visual, tais como o modelo de classes de objetos e
os modelos de sequência, que facilitam o entendimento, facilitam a comunicação da equipe, diminuem
a ambiguidade e permitem a rastreabilidade dos códigos construídos.
A qualidade na fase de construção envolve definir medidas e critérios para determinar se o sistema
está em um nível satisfatório de aceitação. O desenvolvimento iterativo permite a realização de testes
contínuos, tanto nos processos tradicionais quanto nos métodos ágeis.
A figura a seguir apresenta uma visão da aplicação dos testes ao longo do ciclo de desenvolvimento,
usando o desenvolvimento iterativo.
Iteração 1 Iteração 2 Iteração 3
R R R
A/P A/P A/P
I I I
T/I T/I T/I
149
Unidade IV
Na figura, as atividades das iterações são: requisitos (R); análise de projeto (A/P); implementação (I);
testes e implantação (T/I).
Os testes se desenvolvem ao longo dos componentes que vão sendo liberados; são os de unidade e
os de integração. A homologação se dá com o sistema completo ou por módulos, conforme o cliente
vai recebendo.
Uma das formas de se minimizar o controle das mudanças é o uso de ferramentas para gerenciar
versões e pedidos de mudança.
Saiba mais
Resumo
151
Unidade IV
Exercícios
Questão 1. Existem hoje várias propostas de modelos buscando melhorar o processo de
desenvolvimento de software, e todos esses modelos se baseiam no conceito das melhores práticas de
mercado. A partir dessa constatação, têm-se as seguintes afirmativas:
II – Um software deve sempre fornecer valor ao cliente ou agregar valor ao negócio ou à área de
negócio. Este é um princípio para as práticas da ES.
III – Um produto de software é caracterizado por ser consumido por todos os tipos de usuários.
IV – As melhores práticas de mercado e da engenharia de software não têm como foco a manutenção
de sistemas, e sim o desenvolvimento desses sistemas.
152
ENGENHARIA DE SOFTWARE I
V – Os dez princípios das práticas de comunicação são: escute, prepare-se para comunicar, use
um facilitador; comunique-se mais por escrita formal; faça anotações durante as reuniões; busque a
colaboração; fique focado; use desenhos; prossiga, mesmo quando não concordar; e negocie.
I) Afirmativa correta.
Justificativa: o autor Souza ([s.d.]) afirma que, para entender um problema, diversas questões devem
ser consideradas, tais como os interessados, os dados envolvidos, as funções do software, as regras
de negócio envolvidas e quais comportamentos são necessários para resolver o problema. Daí sua
importância e sua essência no processo de software.
Justificativa: agregar valor ao negócio ou fornecer valor para o cliente é considerado um dos
princípios centrais da área de desenvolvimento de software.
Justificativa: as práticas encontradas nos modelos de processos de software atuam tanto no ciclo
de desenvolvimento quanto ao longo da vida do produto de software. O ciclo de evolução do software
exige que as práticas também sejam aplicáveis à manutenção deste.
153
Unidade IV
V) Afirmativa incorreta.
I– O risco somente existirá se as pessoas envolvidas não se envolverem com os objetivos do projeto.
III – Os riscos em projetos de software somente acontecem em relação aos requisitos, que são
levantados e entendidos no início do processo.
V – O uso de desenhos ou diagramas facilita a participação das pessoas durante o levantamento dos
riscos envolvidos no projeto.
154
FIGURAS E ILUSTRAÇÕES
Figura 1
PRESSMAN, R. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006. p. 17.
Figura 2
Grupo Unip-Objetivo.
Figura 3
Figura 8
Grupo Unip-Objetivo.
Figura 9
Adaptada de: CÔRTES, M. L. Modelos de qualidade de software. Cap. 6. Campinas: Unicamp, [s.d.].
Disponível em: <http://www.ic.unicamp.br/~cortes/inf326/transp/cap6.pdf>. Acesso em: 5 mar. 2014.
p. 6-8.
Figura 10
Grupo Unip-Objetivo.
Figura 11
Figura 12
GORDON S. R.; GORDON, J. R. Sistemas de informação: uma abordagem gerencial. São Paulo: LTC,
2006. p. 31.
Figura 14
155
Figura 15
Figura 16
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. p. 35. Disponível em:
<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.
Figura 17
RAMOS, R. A. Processos de desenvolvimento de software. Univasf, Juazeiro, 2009. p. 22. Disponível em:
<http://www.univasf.edu.br/~ricardo.aramos/disciplinas/ESI2009_2/Aula02.pdf>. Acesso em: 13 fev. 2014.
Figura 18
Grupo Unip-Objetivo.
Figura 23
Figura 25
PRESSMAN, R. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006. p. 70.
Figura 27
Figura 28
Adaptada de: ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development with iconix process.
EUA: Appress, 2005, p. 21.
Figura 29
Adaptada de: ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development with iconix process.
EUA: Appress, 2005, p. 21.
156
Figura 30
Adaptada de: ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development with iconix process.
EUA: Appress, 2005, p. 21.
Figura 31
Adaptada de: ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile development with iconix process.
EUA: Appress, 2005. p. 45.
Figura 32
Grupo Unip-Objetivo.
Figura 40
ABE, M. T. MS Project. São Paulo: Escola Politécnica da Universidade de São Paulo, 2000. Disponível
em: <http://www.lem.ep.usp.br/Pef411/~Marcel%20Abe/Ms%20Project98.htm>. Acesso em: 17 abr.
2014.
Figura 42
Adaptada de: YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron
Books, 1998. p. 8.
Figura 43
Adaptada de: YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron
Books, 1998. p. 8.
Figura 46
LUCRÉDIO, D. Uma abordagem orientada a modelos para reutilização de software. 2009. 138 p. Tese
(Doutorado em Ciências) – Instituto de Ciências Matemáticas e de Computação, Universidade de São
Paulo, São Carlos, 2009. p. 40. Disponível em: <http://www.teses.usp.br/teses/disponiveis/55/55134/
tde-02092009-140533/>. Acesso em: 5 mar. 2014.
Figura 47
Grupo Unip-Objetivo.
157
REFERÊNCIAS
ABE, M. T. MS Project. São Paulo: Escola Politécnica da Universidade de São Paulo, 2000. Disponível
em: <http://www.lem.ep.usp.br/Pef411/~Marcel%20Abe/Ms%20Project98.htm>. Acesso em: 17 abr.
2014.
AMBYSOFT. How agile are you? 2010 survey results. Ambysoft, 2010. Disponível em: <http://www.
ambysoft.com/surveys/howAgileAreYou2010.html>. Acesso em: 13 fev2014.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). Norma ABNT NBR ISO/IEC 12207: engenharia
de sistemas e software – processos de ciclo de vida de software. Rio de Janeiro: ABNT, 2000.
BARR, A; FEIGENBAUM, E. The handbook of artificial intelligence. Los Altos: William Kaufmann, 1981. v.
I-II.
BARRETO, L. R.; PREZOTO, M. G. Introdução a sistemas especialistas 2010. Monografia para conclusão
de matéria (Mestrado em Tecnologia para Sistemas e Fenômenos Complexos) – Faculdade de
Tecnologia, Universidade Estadual de Campinas, Campinas, 2010. Disponível em: <http://www.
ft.unicamp.br/liag/wp/monografias/monografias/2010_IA_FT_UNICAMP_sistemasEspecialistas.pdf>.
Acesso em: 15 abr. 2014.
BLEAKLEY, G.; COLLYER, K.; SCOULER, J. Best practices for software development teams. IBM, Armonk,
17 sept. 2013. Disponível em: <http://www.ibm.com/developerworks/rational/library/systems-
software-lifecycle-development/systems-software-lifecycle-development-pdf.pdf>. Acesso em: 31
mar. 2014.
BROCKA, B. M.; BROCKA, S. Gerenciamento da qualidade. São Paulo: Makron Books, 1994.
158
CAETANO, C. Dividir, conquistar e integrar: conceitos de integração contínua para testadores ágeis.
Linha de Código, [s.d.]. Disponível em: <http://www.linhadecodigo.com.br/artigo/1252/dividir-
conquistar-e-integrar-conceitos-de-integracao-continua-para-testadores-ageis.aspx>. Acesso em: 3
fev. 2014.
CLEANROON software engineering. University of Texas, Arlington, [s.d.]. Disponível em: <http://www.
uta.edu/cse/levine/fall99/cse5324/cr/clean/page.html>. Acesso em: 31 mar. 2014.
COCKBURN, A. Crystal Clear: A Human-powered methodology for small teams. EUA: Addison-Wesley,
2004.
CONCEIÇÃO SILVA, M. A.; RORIZ FILHO, H.; NUNES SILVA, H. F. Análise do Ba durante o processo Scrum.
In: SIMPÓSIO DE ENGENHARIA DE PRODUÇÃO, 17, 2010, Bauru. Anais... Bauru, 2010. Disponível em:
<http://massimus.com/download/analise-do-ba-durante-o-processo-scrum/>. Acesso em: 17 abr.
2014.
ENGELMORE, R. S.; FEIGENBAUM, E. Expert systems and artificial intelligence. WTEC Hyper-Librarian,
1993.
FALCONI, C. V. TQC: controle da qualidade total (no estilo japonês). Belo Horizonte: UFMG, 1992.
FAZANO, C. A. Qualidade: a evolução de um conceito. São Paulo: Banas Qualidade, 2006. n. 172.
159
FERNANDES, A. A.; KUGLER, J. L. C. Gerência de projetos de sistemas. Rio de Janeiro: Livros Técnicos e
Científicos, 1989.
FERREIRA, A. B. H. Dicionário Aurélio básico da língua portuguesa. Rio de Janeiro: Nova Fronteira,
1988.
FIGUEIREDO, I. L. Tipos de sistemas de informação na empresa, Oficina da Net, Santa Cruz do Sul, 5 jan.
2011. Disponível em: <http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informacao_
na_empresa>. Acesso em: 3 abr. 2014.
FURLAN, J. D. Modelagem de objetos através da UML. São Paulo: Makron Books, 1998.
GORDON S. R.; GORDON, J. R. Sistemas de informação: uma abordagem gerencial. São Paulo: LTC,
2006.
HAAG, C.; DONOVAN, P. Management information systems: for the information age. Nova Iorque:
McGraw-Hill, 2000. p. 136-40.
IEEE 1028. IEEE standard for software reviews and audits. EUA: Institute of Electrical Electronic
Engineers Standards, 2008.
JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language: user guide. Massachusetts:
Addison Wesley, 1999.
KEEN, P. G. W. Decision support systems: a research perspective. In: FICK, G.; SPRAGUE JUNIOR, R. H.
Decision support systems: issues and challenges. Oxford: Pergamon, 1980.
160
KOSCIANSKI, A; SOARES, M. S. Qualidade de software. São Paulo: Novatec, 2007.
KROENKE, D. M. Banco de dados: fundamentos, projetos e implementação. Rio de Janeiro: LTC, 1998.
KRUCHTEN, P. The nature of software: what’s so special about software engineering? developerWorks,
Armonk, 29 Apr. 2004. Disponível em: <https://www.ibm.com/developerworks/rational/library/4700-
pdf.pdf>. Acesso em: 3 abr. 2014.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orientados a objetos e
ao processo unificado. 2. ed. Porto Alegre: Bookman, 2004.
LAUDON, C. K; LAUDON, J. D. Sistemas de informação gerenciais. 5. ed. São Paulo: Pearson Prentice
Hall, 2004.
LINGER, R. C.; TRAMMELL, C. J. Cleanroom software engineering reference model: version 1.0. nov.
1996. Disponível em: <http://resources.sei.cmu.edu/asset_files/technicalreport/1996_005_001_16502.
pdf>. Acesso em: 31 mar. 2014.
LUCRÉDIO, D. Uma abordagem orientada a modelos para reutilização de software. 2009. 138 p. Tese
(Doutorado em Ciências) – Instituto de Ciências Matemáticas e de Computação, Universidade de São
Paulo, São Carlos, 2009. Disponível em: <http://www.teses.usp.br/teses/disponiveis/55/55134/tde-
02092009-140533/>. Acesso em: 5 mar. 2014.
MARAKAS, G. M. Decision support systems in the twenty-first century. Upper Saddle River: Prentice
Hall, 1999.
MEDEIROS, E. Desenvolvendo software com UML. São Paulo: Makron Books, 2004.
MEYER, B. Object-oriented software construction. 2. ed. Rio de Janeiro: Prentice Hall, 1997.
161
MICHAELIS. Dicionário de português online. 2009. Disponível em: <http://michaelis.uol.com.br/
moderno/portugues/index.php?lingua=portugues-portugues&palavra=metodologia>. Acesso em 17
abr. 2014.
NONAKA, I.; TAKEUCHI, H. The new product development game. Harvard Business Review, Harvard, 1º
Jan. 1986.
OMG. Business process model and notation (BPMN). EUA: OMG, 2011. Disponível em: <http://www.
omg.org/spec/BPMN/2.0/PDF/>. Acesso em: 17 abr. 2014.
OSLON, T. How to improve your software inspection process. In: SEPG CONFERENCE, 99., 1999, EUA.
Proceedings... EUA: SEPG, 1999.
PALADINI, E. P. et al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005.
PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. São Paulo: LTC, 2003.
PEZZÉ, M.; YOUNG, M. Teste e análise de software: processos, princípios e técnicas. Porto Alegre:
Bookman, 2008.
POWER, D. J. Web-based and model-driven decision support systems: concepts and issues. In:
AMERICAS CONFERENCE ON INFORMATION SYSTEMS, 2000, California. Proceedings… California:
AMCIS, 2000.
PRADO, J. C. S. Gerenciando a qualidade de software com base em requisitos. Rio de Janeiro, [s.d.].
Disponível em: <http://www-di.inf.puc-rio.br/~julio/Slct-pub/Livro-qualidade.pdf>. Acesso em: 31 mar.
2014.
162
______. Engenharia de software. 6. ed. Porto Alegre: McGraw Hill, 2006.
PSP. Personal software process. Body of Knowledge, version 2.0, 2009. Disponível em: <http://
resources.sei.cmu.edu/asset_files/SpecialReport/2009_003_001_15029.pdf>. Acesso em: 15 abr. 2014.
ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software: teoria e prática. São Paulo:
Prentice Hall, 2001.
REED JÚNIOR, P. R. Desenvolvendo aplicativos com Visual Basic e UML. São Paulo: Makron Books,
2000.
ROSEMBERG, D.; STEPHES, M.; COLLINS-COPE, M. Agile Development with Iconix Process. EUA:
Appress, 2005.
ROUILLER, A. C. Gerência de projetos de software. Apostila. Lavras: Ufla/Faepe, 2008. Disponível em:
<https://gerpro2008.googlecode.com/files/Apostila_GERENCIA_DE_PROJETOS_DE_Software.pdf>.
Acesso em: 17 abr. 2014.
SCHWABER, K. Agile software development with Scrum. EUA: Prentice Hall, 2002.
______. Agile software management with Scrum. EUA: Microsoft Press, 2004.
SENGE, P. M. A quinta disciplina: arte, teoria e prática da organização de aprendizagem. São Paulo:
Best Seller, 1990.
SHIBA, S. TQM: quatro revoluções na gestão da qualidade. Porto Alegre: Bookman, 1997.
SOUZA, E. J. Metodologia de implantação de software corporativo. Recife: ATI, 2009. Disponível em:
<http://www2.ati.pe.gov.br/c/document_library/get_file?p_l_id=144654&folderId=144374&name=D
LFE-15402.pdf>. Acesso em: 2 abr. 2014.
163
SOUZA, G. R. Práticas da engenharia de software. IFRN, João Câmara, [s.d.]. Disponível em: <http://
docente.ifrn.edu.br/givanaldorocha/disciplinas/engenharia-de-software-licenciatura-em-informatica/
praticas-de-engenharia-de-software>. Acesso em: 13 fev. 2014.
SPRAGUE, R. H.; CARLSON, E. D. Building effective decision support systems. Englewood Cliffs:
Prentice-Hall, 1982.
STEPHENS, M.; ROSENBERG, D. Extreme programming refactored: the case against SP. EUA: Apress, 2003.
TELES, V. M. Um estudo de caso da adoção das práticas e valores do extreme programming. 2005. 90 f.
Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005.
Disponível em: <http://desenvolvimentoagil.com.br/xp/dissertacaoXP.pdf>. Acesso em: 16 abr. 2014.
TREVISANI, A. T. et.al. Gerenciando qualidade, prazos e custos em projetos de SI. In: SEMEAD, 7,
2004, São Paulo. Anais... São Paulo: FEA/USP, 2004. Disponível em: <http://www.ead.fea.usp.br/
Semead/7semead/paginas/artigos%20recebidos/mqi/MQI09_-_Gerenciando_qualidade.PDF>. Acesso
em: 13 fev. 2014.
TSP. Team software process. Body of Knowledge (BOK). EUA. Software Engineering Institute. 2010:
Disponível em: <http://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15254.pdf>.
Acesso em: 15 abr. 2014.
TURBAN, E. Decision support and expert systems: management support systems. Englewood Cliffs:
Prentice Hall, 1995.
TURBAN, E.; MCLEAN, E.; WETHERBE, J. Tecnologia da informação para gestão. 3. ed. Porto Alegre:
Bookman, 2004.
VIANNA, M. Reuniões de levantamento: como torná-las produtivas? Linha de Código, Rio de Janeiro,
[s.d.]. Disponível em: <http://www.linhadecodigo.com.br/artigo/159/reunioes-de-levantamento-como-
torna-las-produtivas.aspx>. Acesso em: 2 abr. 2014.
WOOD, J.; SILVER, D. Joint application development. EUA: John Wiley & Sons, 1995.
YOURDON, E.; ARGILA, C. Análise e projeto orientados a objetos. São Paulo: Makron Books, 1998.
164
______. Walkthroughs and inspections. In: ______. Modern structured analysis. 6. ed. Upper Saddle
River: Prentice Hall, 2000.
Sites
<http://astah.net/download#community>.
<http://alistair.cockburn.us/crystal>.
<http://homepages.dcc.ufmg.br/~wilson/praxis/>.
<http://massimus.com>.
<http://umbrello-uml-modeller.soft112.com/>.
<http://www.abnt.org.br>.
<http://www.fnq.org.br/>.
<http: www.ibqts.com.br>.
<http://www.sei.cmu.edu/>.
<http://www.softex.br/mpsbr/>.
<http://www.swebok.org>.
<http://www.uml.org>.
165
166
167
168
Informações:
www.sepi.unip.br ou 0800 010 9000