Engenharia de Software

Transcrição

Engenharia de Software
Metodologias de Desenvolvimento de
Sistemas
PDF gerado usando o pacote de ferramentas em código aberto mwlib. Veja http://code.pediapress.com/ para mais informações.
PDF generated at: Wed, 29 Sep 2010 14:56:00 UTC
Conteúdo
Páginas
Engenharia de software
1
Software Engineering Body of Knowledge
8
Requisitos de Software
9
Projeto de Software
18
Teste de software
18
Gerência de Configuração de Software
25
Processos de Engenharia de Software
34
Qualidade de Software
36
Modelos ciclo de vida
39
Análise Estruturada
43
Projeto Estruturado
43
Programação Estruturada
44
Análise Essencial
44
SADT
48
DFD
48
Modelo de Entidades e Relacionamentos
49
Orientação a Objetos
49
Rational Unified Process
52
Scrum
60
Programação extrema
64
Microsoft Solution Framework
67
Diagrama de contexto
71
Diagrama de fluxos de dados
71
Diagrama entidade relacionamento
72
Dicionário de dados
73
Tabela de decisão
74
Árvore de decisão
75
Diagrama de transição de estados
75
Processo de desenvolvimento de software
77
Análise de requisitos de software
81
Especificação de Programa
81
Arquitetura de software
82
Programação de computadores
86
Teste de Software
89
Documentação de software
96
Manutenção de software
97
CMMI
98
SPICE
102
ISO 12207
104
MPS/Br
104
Referências
Fontes e Editores da Página
108
Fontes, Licenças e Editores da Imagem
110
Licenças das páginas
Licença
111
Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento
e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas,
objetivando organização, produtividade e qualidade.
Atualmente, essas tecnologias e práticas englobam linguagens de programação, banco de dados, ferramentas,
plataformas, bibliotecas, padrões, processos e a questão da Qualidade de Software.
Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que
permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo
suas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar o
processo de desenvolvimento de um sistema de informação Sistema computacional, pois ambos se confundem!
Definição
Friedrich Ludwig Bauer foi o primeiro a defini-la como sendo: "Engenharia de Software é a criação e a utilização de
sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe
eficientemente em máquinas reais". O próprio significado de engenharia já traz os conceitos de criação, construção,
análise, desenvolvimento e manutenção.
A Engenharia de Software se concentra nos aspectos práticos da produção de um sistema de software, enquanto a
ciência da computação estuda os fundamentos teóricos dos aspectos computacionais.
O termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO Conference on Software
Engineering (Conferência sobre Engenharia de Software da OTAN). Sua criação surgiu numa tentativa de contornar
a crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de
sistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes
abstratos de software (estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos,
objetos ou agentes e interconectados entre si, compondo a arquitetura do software, que deverão ser executados em
sistemas computacionais.
Os fundamentos científicos envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro
especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Além
disto, deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento. Empresas
desenvolvedoras de software passaram a empregar esses conceitos sobretudo para orientar suas áreas de
desenvolvimento, muitas delas organizadas sob a forma de Fábrica de Software.
A Engenharia de Sistemas é uma área mais ampla por tratar de todos os aspectos de sistemas baseados em
computadores, incluindo hardware e engenharia de processos além do software.
Áreas de Conhecimento
Segundo o SWEBOK (Corpo de Conhecimento da Engenharia de Software), versão 2004, as áreas de conhecimento
da Engenharia de Software são:
•
•
•
•
•
Requisitos (Requirements) de Software
Projeto (Design) de Software
Construção (Construction) de Software
Teste (Testing) de Software
Manutenção (Maintenance) de software
• Gerência de Configuração de Software
• Gerência de Engenharia de Software
1
• Processos de Engenharia de Software
• Ferramentas e Métodos de Engenharia de Software
• Qualidade (Quality) de Software
Conforme Pressman, a Engenharia de Software (ES) é uma tecnologia em camadas. E a base de todas essas camadas
é o foco na qualidade do software desenvolvido. Portanto, inclusive do ponto de vista didático, é interessante
estudarmos a ES em suas camadas de Processo, Métodos e Ferramentas.
Processo de Software
Processo de software, ou processo de engenharia de software, é uma seqüência coerente de práticas que objetiva o
desenvolvimento ou evolução de sistemas de software. Estas práticas englobam as atividades de especificação,
projeto, implementação, testes e caracterizam-se pela interação de ferramentas, pessoas e métodos.
SEE e PSEE são os ambientes voltados ao desenvolvimento e manutenção de processos. O projeto ExPSEE é uma
continuação dos estudos de processos, principalmente do ambiente PSEE.
Devido ao uso da palavra projeto em muitos contextos, por questões de clareza, há vezes em que se prefira usar o
original em inglês design.
Modelos de Processo de Software
Um modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto como
uma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, oferece
uma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente o
progresso do projeto.
Exemplos de alguns modelos de processo de software;
• Modelos ciclo de vida
• Sequencial ou Cascata (do inglês waterfall) - com fases distintas de especificação, projeto e desenvolvimento.
• Desenvolvimento iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples de Requisitos
de Software e interativamente alcança evoluções subseqüentes das versões até o sistema todo estar implementado
• Evolucional ou Prototipação - especificação, projeto e desenvolvimento de protótipos.
• V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que permite que se compare com
outros modelos mais modernos.
• Espiral - evolução através de vários ciclos completos de especificação, projeto e desenvolvimento.
• Componentizado - reuso através de montagem de componentes já existentes.
• Formal - implementação a partir de modelo matemático formal.
• Ágil
• RAD
• Quarta geração
É muito importante o desenvolvimento do software.
2
Modelos de Maturidade
Os modelos de maturidade são um metamodelo de processo. Eles surgiram para avaliar a qualidade dos processos de
software aplicados em uma organização (empresa ou instituição). O mais conhecido é o Capability Maturity Model
Integration (CMMi), do Software Engineering Institute - SEI.
O CMMi pode ser organizado através de duas formas: Contínua e estagiada. Pelo modelo estagiado, mais tradicional
e mantendo compatibilidade com o CMM, uma organização pode ter sua maturidade medida em 5 níveis:
• Nível 1 - Caótico;
• Nível 2 - Capacidade de repetir sucessos anteriores pelo acompanhamento de custos, cronogramas e
funcionalidades;
• Nível 3 - O processo de software é bem definido, documentado e padronizado;
• Nível 4 - Realiza uma gerência quantitativa do processo de software e do produto;
• Nível 5 - Usa a informação quantitativa para melhorar continuamente e gerenciar o processo de software.
O CMMi é um modelo de maturidade recentemente criado com o fim de agrupar as diferentes formas de utilização
que foram dadas ao seu predecessor, o CMM.
O (MPS.BR), ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria e
um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de
desenvolvimento de software no Brasil.
Metodologias e Métodos
O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular.
Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma
metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas
diferenciadas para realizar algo.[1]
Assim teríamos, por exemplo, a Metodologia Estruturada, na qual existem vários métodos, como Análise Estruturada
e Projeto Estruturado (muitas vezes denominados SA/SD, e Análise Essencial). Tanto a Análise Estruturada quanto a
Análise Essencial utilizam a ferramenta Diagrama de Fluxos de Dados para modelar o funcionamento do sistema.
• Metodologia Estruturada
• Análise Estruturada
• Projeto Estruturado
• Programação Estruturada
• Análise Essencial
• SADT
• DFD - Diagrama de Fluxo de Dados
• MER - Modelo de Entidades e Relacionamentos
• Metodologia Orientada a Objetos
• Orientação a Objetos
• Rational Unified Process ( RUP )
• Desenvolvimento ágil de software
•
•
•
•
Feature Driven Development ( FDD )
Enterprise Unified Process (EUP)
Scrum (Scrum)
Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
• Programação extrema ( XP )
• Outras Metodologias
3
• Microsoft Solution Framework ( MSF )
Modelagem
A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o
entendimento e comunicação do produto final que será desenvolvido.
A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a
complexidade (favorecendo a precisão) do modelo.
Para a modelagem podemos citar 3 métodos:
• Análise estruturada, criada por Gane & Searson;
• Análise Essencial, criada por Palmer & McMenamin e Ed. Yourdon;
• UML criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh (veja exemplos).
Atualmente a modelagem mais recomendada, e sendo a mais comum, é a utilização da linguagem UML.
Ferramentas, Tecnologias e Práticas
A engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência da
computação, enfocando seu impacto na produtividade e qualidade de software.
Destacam-se o estudo de linguagem de programação, banco de dados e paradigmas de programação, como:
•
•
•
•
•
Programação estruturada
Programação funcional
Programação orientada a objetos
Componentes de Software
Programação orientada a aspecto
Ferramentas
Outro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essa
classificação abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de software,
desde a análise de requisitos e modelagem até programação e testes.
Os ambientes de desenvolvimento integrado (IDEs) têm maior destaque e suportam, entre outras coisas:
•
•
•
•
•
•
•
•
•
•
•
Editor
Compilador
Debug
Geração de código
Modelagem
Deploy
Testes não automatizados
Testes automatizados
Refatoração (Refatoring)
Gestão de Riscos nos projectos de Software
Uso da Prototipagem na Eng. de Requisitos
4
Gerência de Projetos
A gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos
estabelecidos, levando em conta sempre as limitações de orçamento e tempo.
A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com
processo de desenvolvimento com baixa padronização.
Planejamento
O planejamento de um projeto de desenvolvimento de software inclui:
•
•
•
•
•
•
Análise Econômica de Sistemas de Informações
organização do projeto (incluindo equipes e responsabilidades)
estruturação das tarefas (do inglês WBS - work breakdown structure)
cronograma do projeto (do inglês project schedule)
análise e gestão de risco
estimativa de custos
Essas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em
relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de
novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente
a produtividade.
A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas
técnicos. Esses fatores requerem uma análise de riscos cuidadosa.
Além da própria identificação dos riscos, há que ter em conta a sua gestão. Seja evitando, seja resolvendo, os riscos
necessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.
Análise de Requisitos
As atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema de
software. Em resumo, requisito é uma necessidade que o software deve cumprir.
Há várias interpretações e classificações sobre requisitos, entre elas:
•
•
•
•
funcional
não funcional
de usuário
de sistema
É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja
mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de
sistemas de software, principalmente sobre o custo de cada requisito.
• Estudo de Viabilidade (Levantamento de Requisitos)
A Engenharia de requisitos é um processo que envolve todas as atividades exigidas para criar e manter o documento
de requisitos de sistema (SOMMERVILLE). Segundo RUMBAUGH, alguns analistas consideram a engenharia de
Requisitos como um processo de aplicação de um método estrutura como a analise orientada a objetos. No entanto, a
Engenharia de requisitos possui muito mais aspectos do que os que estão abordados por esses métodos.
Abaixo um pequeno Processo de Engenharia de Requisitos (SOMMERVILLE).
Estudo da viabilidade → "Relatório de Viabilidade" Obtenção e Analise de Requisitos → "Modelos de Sistema"
Especificação de Requisitos → "Requisitos de Usuário e de Sistema" Validação de Requisitos → "Documento de
Requisitos"
5
6
O primeiro processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os resultados deste processo
devem ser um relatório com as recomendações da viabilidade técnica ou não da continuidade no desenvolvimento do
Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido, deverá abordar
fundamentalmente as seguintes questões:
O Sistema proposto contribui para os objetivos gerais da organização? O Sistema poderá ser implementado com as
tecnologias dominadas pela equipe dentro das restrições de custo e de prazo? Ou precisa de treinamentos adicionais?
O Sistema pode ser integrado, e é compatível com os outros sistemas já em operação?
Gestão
•
•
•
•
•
Pessoal
Produto
Processo
Projeto
Material
Histórico
A Engenharia de Software (ES) surgiu em meados dos anos 1970 numa tentativa de contornar a crise do software e
dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de software
complexos. Um sistema de software complexo se caracteriza por um conjunto de componentes abstratos de software
(estruturas de dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos, objetos ou agentes
interconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemas
computacionais.
ES no Presente e Tendências
Atualmente existe um destaque todo especial para a Engenharia de Software na Web. Também utilizado por
Presmann a sigla WebE, é o processo usado para criar WebApps (aplicações baseadas na Web) de alta qualidade.
Embora os princípios básicos da WebE sejam muito próximos da Engenharia de Software clássica, existem
peculiaridades específicas e próprias.
Com o advento do B2B (e-business) e do B2C (e-commerce), e ainda mais com aplicações para a Web 2.0, maior
importância ficou sendo esse tipo de engenharia. Normalmente adotam no desenvolvimento a arquitetura MVC
(Model-View-Controller).
Outra área de tendência em Engenharia de Software trata da aplicação de técnicas otimização matemática para a
resolução de diversos problemas da área. A área, denominada Search-based software engineering, ou Otimização em
engenharia de software em Português, apresenta vários resultados interessantes.[2] Para mais detalhes em Português,
ver texto com aplicações da otimização em engenharia de software [3].[4]
[1] Veja mais detalhes em Metodologia (engenharia de software)
[2] HARMAN, M., JONES, B.F., Search-based software engineering, Information and Software Technology, 2001, pp. 833-839.
[3] http:/ / goes. comp. uece. br/ resources/
Search-based%20Software%20Engineering%20-%20Aplicação%20de%20Metaheurísticas%20em%20Problemas%20da%20Engenharia%20de%20Software%20R
pdf
[4] FREITAS, F.G., MAIA, C.L.B., COUTINHO, D.P., CAMPOS, G.A.L., SOUZA, J.T., Aplicação de Metaheurísticas em Problemas da
Engenharia de Software: Revisão de Literatura (http:/ / goes. comp. uece. br/ resources/ Search-based Software Engineering - Aplicação de
Metaheurísticas em Problemas da Engenharia de Software Revisão de Literatura (Otimização em Engenharia de Software). pdf), II Congresso
Tecnológico Infobrasil, 2009,
Bibliografia
• MAGELA, Rogerio. Engenharia de Software Aplicada: Princípios (volume 1). Alta Books. 2006.
• MAGELA, Rogerio. Engenharia de Software Aplicada: Fundamentos (volume 2). Alta Books. 2006.
• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5
• PRESSMAN, Roger. Software Engineering: A Practitioner's Approach, 6ªedição, Mc Graw Hill, 2005.
• ECONÔMICA DE SISTEMAS DE INFORMAÇÕES. (http://www.editoraixtlan.com/livros.htm''ANÁLISE)
(ISBN 978-85-909374-7-0) Editora Ixtlan. Autor : Sergio Kaminski. Comentário: Mostra todas as etapas de
desenvolvimento do software, relacionando ao lucro,receita e custo.
Ligações externas
• Site dos alunos da Graduação em Engenharia de Software da Universidade Federal de Goiás - UFG (http://www.
engenhariadesoftwarebrasil.com)
• Bacharelado em Engenharia de Software (http://engenhariadesoftware.inf.br/home) ( Graduação em
Engenharia de Software (http://engenhariadesoftware.inf.br/home)) Curso superior oferecido pelo Instituto de
Informática --- Universidade Federal de Goiás.
• GPES (http://www.gpes.dcc.ufmg.br/) Grupo de Pesquisa em Engenharia de Software do Departamento de
Ciência da Computação da Universidade Federal de Minas Gerais.
• Praxis - Processo de desenvolvimento de software com enfoque educacional
• Software da gerência de OEE (http://www.capstonemetrics.com/files/understanding-oee.html)
• Podcasts bem interessantes (em português) sobre áreas de interesse da Engenharia de Software (http://www.
improveit.com.br/podcast) CMMI, MPS.BR, Scrum, Extreme Programming e Lean Software Development
• Revista Engenharia de Software (http://www.devmedia.com.br/esmag) Revista sobre Engenharia de Software
em portugues
• Graduação em Engenharia de Software na Universidade de Brasilia - FGA (http://www.fga.unb.br/unbgama)
Novo Campus da Universidade de Brasília
• Grupo de Otimização em Engenharia de Software da Universidade Estadual do Ceará (GOES.UECE) (http://
goesuece.yolasite.com) Grupo de Otimização em Engenharia de Software da Universidade Estadual do Ceará
(GOES.UECE)
Ver também
•
•
•
•
•
•
Desenvolvimento de software
Qualidade de software
Análise Econômica de Sistemas de Informações
Matriz CRUD
Otimização em engenharia de software
7
O Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um documento
criado sob o patrocínio da IEEE com a finalidade de servir de referência em assuntos considerados, de forma
generalizada pela comunidade, como pertinentes a área de Engenharia de Software.
O SWEBOK apresenta uma classificação hierárquica dos tópicos tratados pela Engenharia de Software, onde o nível
mais alto são as Áreas do Conhecimento.
Objetivos
•
•
•
•
•
Promover uma visão consistente da engenharia de software no mundo
Clarear e marcar as fronteiras entre a engenharia de software e as outras disciplinas relacionadas
Caracterizar o conteúdo da disciplina de engenharia de software
Classificar em tópicos a área de conhecimento da engenharia de software
Prover uma fundação para o desenvolvimento do currículo, para certificação individual e para licenciamento de
material
Áreas do Conhecimento
•
•
•
•
•
•
•
•
•
•
Projeto de Software
Construção de Software
Teste de Software
Manutenção de Software
Gerência da Engenharia de Software
Processo de Engenharia de Software
Ferramentas e Métodos da Engenharia de Software
Disciplinas Relacionadas
•
•
•
•
•
•
•
•
Ciência da Computação
Engenharia da Computação
Engenharia de Sistemas
Ergonomia de Software
Gestão
Gestão da Qualidade
Gestão de Projeto
Matemática
8
Crítica
Como toda classificação hierárquica, foram tomadas decisões específicas sobre em que posição da hierarquia os
tópicos deveriam aparecer, e que podem não ser considerados ideais por outros pesquisadores.
Ver também
• Engenharia de software
• PMBOK
Ligações externas
• SWEBOK [1] - Neste sítio é possível baixar o guia pela Web.
Referências
[1] http:/ / www. swebok. org
A engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as atividades
que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo.
Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projeto, determinam se este
é ou não viável e se deve prosseguir para a identificação dos requisitos.
O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares, 2005):
1.
2.
3.
4.
Identificação.
Análise e negociação.
Especificação e documentação.
Validação.
Uma outra atividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à
produção do documento (isto é, a sua "manutenção"), é a gestão dos requisitos ( change management [1], sendo que
as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza
do negócio (e consequentemente nos requisitos), entre outras).
Estudos de viabilidade
Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de
viabilidade.
Tal como o nome sugere, pretende-se com este estudo avaliar se, de um ponto de vista tecnológico e organizacional,
o projeto é viável.
Uma forma de avaliar a viabilidade de um projeto é obter, através da interação com "as partes interessadas" (ou
stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões:
• Será que o sistema contribui para os objetivos da organização?
• Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e
temporais associadas ao projeto, será que o sistema pode ser implementado?
• Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível?
9
A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe
traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvia, são
frequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer seja
por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da
organização.
Deve portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta
informação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbito
do projeto e avaliar a sua viabilidade.
Tipicamente, quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema a
implementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam
familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pela
manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação
com o novo sistema (ou que sejam por ele afetados).
Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo:
• Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização?
• Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas
falhas?
• De que forma é que o sistema irá contribuir diretamente para os objetivos da organização?
• É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que
facilidade é que se consegue partilhar informação entre estes sistemas?
O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do
desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto
e definindo mesmo alguns requisitos de alto nível.
Identificação
Caso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.
Atividades envolvidas
Algumas das atividades envolvidas nesta fase incluem:
• Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o
projeto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o
analista e as partes interessadas.
• Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém
para efeitos de identificação de requisitos convém concentrar as atenções nos utilizadores do sistema.
• Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o
sistema.
• Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser
consensual) e devem ser propostas soluções em conjunto com as partes interessadas.
10
Dificuldades
Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas:
• O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo (o que
é bastante comum).
• Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo).
• Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de
um bom conhecimento do domínio - identificar estas situações.
Técnicas para levantamento de requisitos
Existem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situações, entre as quais
podemos citar:
Entrevistas e Questionários
Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase
inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns fatores:
• Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao entrevistado para
expor as suas ideias sem as enviesar logo à partida.
• Relação pessoal entre os intervenientes na entrevista.
• Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introdução de
um sistema na organização, este pode propositadamente dificultar o acesso à informação.
• Capacidade de seguir um "plano" para a entrevista: na ausência destes planos é natural que haja tendência para
que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto.
Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentação de "querer despachar" sendo os
últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).
Workshops de requisitos
• O Workshop de Requisitos consiste numa técnica usada através de uma reunião estruturada, da qual devem fazer
parte um grupo de analistas e um grupo representando o cliente[2] , para então obter um conjunto de requisitos
bem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes no
workshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo um
facilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes (ainda
que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos e
devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em
workshops é o uso de brainstorming (tempestade de idéias) como forma de gerar um elevado número de ideias
numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflita
os requisitos e decisões tomadas sobre o sistema a implementar.
11
Cenários
• Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de
exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do
seu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática e
aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos:
• Estado do sistema no início do cenário.
• Sequência de eventos esperada (na ausência de erros) no cenário.
• Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados.
• Outras atividades que podem ser executadas ao mesmo tempo que as deste cenário.
• Estado do sistema depois de o cenário terminar.
Prototipagem
O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na
identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco
definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão
facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo
normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe
podem trazer maior valor acrescentado (principalmente na prototipificação evolutiva, isto é, aquela que mais tarde é
evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise
custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo
particularmente úteis em situações em que a interface com os utilizadores é, para eles, um aspecto crítico.
Estudo etnográfico
Os Estudos Etnográficos é uma análise de componente social das tarefas desempenhadas numa dada organização.
Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de se esperar que esta sinta dificuldade em
articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma
observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar
requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de
registros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode
ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções
"corretamente", pelo que convém ter algum cuidado na escolha do mesmo.
Análise e negociação dos requisitos
Após a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos.
Atividades envolvidas
Algumas das atividades envolvidas na análise de requisitos incluem:
• Classificação: agrupamento de requisitos em "módulos" para facilitar a visão global do funcionamento pretendido
para o sistema.
• Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na
captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante
resolver estes conflitos o mais breve possível.
• Prioritização: consiste na atribuição de uma "prioridade" a cada requisito (por exemplo elevada/média/baixa);
obviamente, este pode ser um fator gerador de conflitos.
• Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade
(de acordo com o que se pretende do sistema).
12
Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir inclusive para as
demais fases.
A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do
futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada
ciclo de trabalho.
Dificuldades
As dificuldades encontradas na análise são de diversas naturezas:
• Fatores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão,
pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto
de vista em detrimento dos demais interessados que irão operar o sistema).
• O ambiente (económico e/ou organizacional) em que a análise é feita possui fatores dinâmicos, e como tal, os
requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são
envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).
Negociações
Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra sem problemas, chegando-se
logo a consensos. Para tanto, faz-se algumas sugestões:
• Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde,
fora de reunião), de preferência nunca tomando partidos.
• Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação.
• Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos.
• Relaxar restrições, quando se torna óbvio que as actuais não conseguem levar a um consenso.
Especificação e documentação
É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos.
Em todos os tipos de especificação há 2 tipos de requisitos a considerar:
• Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma
completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual
o sistema será desenvolvido.
• Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema
deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de:
Utilidade, Confiança, Desempenho, Suporte e Escalabilidade.
Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de
necessidades específicas dos utilizadores, podendo depois ser classificados como funcionais ou não-funcionais.
A documentação produzida poderá ter diferentes destinatários e como tal diferentes objetivos. Podem-se distinguir
três tipos de especificação:
• Especificação de requisitos do utilizador.
• Especificação de requisitos do sistema.
• Especificação do design da aplicação.
A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se
comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" que
o utilizador conheça). Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto
nível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas
13
(esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitos
relativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas de
casos de uso).
Requisitos do utilizador
Os requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistema
será implementado (desde gestores a utilizadores), pelo que são descritos usando apenas (conforme já foi referido)
linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem
algumas dificuldades:
• Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito
longa ou de difícil compreensão.
• Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos
funcionais/não-funcionais e objetivos do sistema torna-se difícil.
• Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar
claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um.
Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do utilizador:
• Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos requisitos).
• Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões
como "O sistema permitirá criar (...)" ou "Deverá ser possível criar (...)" respectivamente. É importante deixar
claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões
de forma consistente ao longo de todo o documento.
• Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo).
• Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma
forma clara quando for absolutamente necessário usá-los.
Requisitos do sistema
Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do
utilizador correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e notações
gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros que
trabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e de
desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, embora
alguns deles sejam ligeiramente diferentes:
• As mesmas palavras podem, de acordo com a interpretação de cada pessoa, designar conceitos diferentes.
• O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando é
que descrições diferentes se referem ou não a requisitos diferentes.
Design da aplicação
Por fim, a especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do
sistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e sua
arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto
deverá ser capaz de "se situar" quando precisar de começar a codificar, compreendendo a forma como a
implementação, em um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de
implementação aprofundados. Não convém cair na tentação de deixar toda a implementação detalhada, uma vez que
convém que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver
problemas encontrados em sub-sistemas de formas que uma especificação inicial da arquitetura não consegue prever.
14
Documento de Especificação de Requisitos
Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação que é a usada
como declaração oficial dos requisitos do sistema.
Este documento, normalmente chamado de Documento de Especificação de Requisitos (Software Requirements
Specification ou SRS) inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades
para diferentes pessoas (Kotonya e Sommerville, 1998):
•
•
•
•
•
Clientes: confirmar a completude dos requisitos e propor alterações.
Gestores: orçamentar o sistema e planejar o processo de desenvolvimento.
Engenheiros: compreender o sistema a desenvolver.
Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos.
Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes.
Existem diversos padrões para este documento, embora não se possa apontar nenhum como o "ideal". Uma estrutura
proposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-1993 (Thayer e Dorfman, 1993).
Validação
Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o
cliente pretende.
À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação,
porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos.
A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados
demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos
têm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têm
um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e
necessidade de refazer muito do trabalho que se julgava já concluído.
Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos
requisitos:
• Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas
envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem
diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente
compreenda e aceite a especificação final obtida.
• Consistência: não devem existir conflitos entre os requisitos identificados.
• Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas
partes interessadas.
• Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema.
• Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser
implementável.
• Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados,
estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema
final corresponde à especificação inicial.
• Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros
motivos, isto é importante para facilitar a gestão futura dos requisitos.
• Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer
às normas usadas ao longo de todo o documento.
15
Técnicas de validação
Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregues:
Revisões dos requisitos
Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta
corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma
conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos
produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que
todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores
finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer
alterações sem produzir efeitos em todos os outros requisitos).
Prototipificação
(Ou prototipação) A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os
utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais
contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo
gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a
versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair
na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva
ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação).
Geração de casos de teste
Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase
de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e
que este poderá ter de ser reconsiderado.
Análise de consistência automática
Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as
ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada
nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.
Recomendações
A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito importante na engenharia de
requisitos e da qual dependem elevados custos a médio e longo prazo.
Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é
bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a
discordâncias numa fase posterior, já com o documento validado e o projeto em desenvolvimento ou concluído.
Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado.
Gestão de requisitos
Os requisitos de um sistema, em especial em sistemas minimamente grandes, estão em evolução constante.
De um modo geral, isto pode suceder em razão do problema abordado não conseguir ficar completamente definido
antes da produção do documento de requisitos (ou mesmo antes de o sistema ser implementado) ou, por outro lado,
pode também acontecer por os próprios requisitos se alterarem no decorrer do projeto (reflectindo evoluções
tecnológicas ou alterações na organização na qual é usado).
É natural que surjam requisitos por parte dos utilizadores por diversos motivos:
16
• Conforme já foi referido, a resolução de conflitos entre requisitos resulta num compromisso que procura
equilibrar as necessidades das diferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com o
uso do sistema é que é possível avaliá-lo convenientemente. Para além de conflitos entre requisitos de diferentes
utilizadores do sistema, há ainda a considerar os conflitos entre utilizadores e "elementos executivos" da
organização, isto é, aqueles que têm o poder de decisão e que podem impôr requisitos perante os analistas (que
podem não contribuir para os objetivos da organização).
• A orientação do negócio da organização pode-se alterar, nova legislação ou regulamentação pode pôr em causa
alguns dos requisitos do sistema, alterações a nível tecnológico podem surgir na organização (afectando
particularmente, no caso de alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemas
que precisem de suporte, a nível de interação, por parte do sistema implementado, e toda uma série de alterações
imprevisíveis pode surgir levando a que o sistema tenha de se adaptar a todo este tipo de requisitos.
Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplo requisitos que dependam da
entidade política governante num dado momento), enquanto que outros são relativamente estáveis (os que se referem
à natureza do negócio (domínio) propriamente dita).
Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos de engenharia de requisitos
(para os "novos" requisitos, isto é, os "antigos" que sofreram alterações). Como tal, o planejamento é uma parte
importante da gestão de requisitos. Devem estar definidas desde o início da gestão de requisitos políticas para:
• Identificação de requisitos: identificação unívoca em especial para facilitar a rastreabilidade.
• Processo de gestão de mudanças a utilizar: conjunto de atividades que permitem avaliar o custo e impacto das
alterações.
• Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem precisar de manter
associada a cada requisito informação como a parte interessada que a propôs, dependências de outros requisitos e
associação a módulos específicos do design do sistema.
• Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser elevada, sendo o
uso de ferramentas CASE aconselhado.
Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um modo controlado), é
importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as
seguintes três fases:
• Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos
originais e proposta de alteração a fazer aos requisitos do sistema.
• Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do
impacto da alteração no sistema.
• Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e
implementação.
É importante seguir este processo conforme foi enunciado já que cair na tentação de implementar a alteração
directamente e só depois, retrospectivamente, actualizar os requisitos pode levar a dessincronização entre requisitos e
implementação.
[1] http:/ / en. wikipedia. org/ wiki/ Change_management#Change_management_in_information_technology
[2] este grupo deve ser escolhido levando-se em conta a organização e o contexto em que o sistema será usado
17
Referências
• Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian
Sommerville. Wiley. 1998.
• Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001.
• Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer
Society Press. 1993.
• Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares.
2005.
Ferramentas
Projeto SER::Sistema de Engenharia de Requisitos (https://sourceforge.net/p/sersistemadeeng)
Projeto de Software
1. REDIRECIONAMENTO Projeto de software
Teste de software
O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao
contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.
O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e
que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito.
Visão geral
Não se pode garantir que todo software funcione corretamente, sem a presença de erros,[1] visto que os mesmos
muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanho
do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a
complexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se torna
impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do teste
acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes.[2]
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou
pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. A
implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é o
resultado de um ou mais defeitos em algum aspecto do sistema.
O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação
pode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na norma
ISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De forma
geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações,
outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente,
normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de
verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.
Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho. Esta deve ter como
base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão
18
Teste de software
definidos os passos necessários para chegar ao produto final esperado.
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um produto
final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.
Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia
de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma
crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais
pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer
com que uma sólida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha
um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de
software.
Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por
entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e
ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes,
como por exemplo os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI.
Outro factor com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que
serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina
dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente,
seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e
financeiros.
De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhões de
dólares à economia dos Estados Unidos. Mais de um terço do custo poderia ser evitado com melhorias na
infraestrutura do teste de software.[3]
Princípios
Para Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, de
forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente
analisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as
condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a implementação e
para a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de erros, enquanto a
entidade de programação possui uma visão construtiva, em busca da implementação de uma especificação.
Myers também aborda o esforço para se construir casos de teste. Deve-se evitar testes descartáveis, pois a qualidade
do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de regressão, que
permite quantificar a evolução da qualidade de software, mantendo e executando novamente testes realizados
anteriormente.
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência de
erros num certo trecho de código é proporcional à quantidade de erros já encontradas anteriormente. Basicamente,
erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais propensos a ter erros
que outros.
19
Teste de software
Técnicas
Existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito
utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas
orientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo
principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas algumas das
técnicas mais conhecidas.
Caixa-branca
Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno
do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para
avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos,
códigos nunca executados.
Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a
construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O
testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e
componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram
todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por
estruturas de condições são testadas.
Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de
teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou
testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas
pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade
de erros de codificação e a busca de utilização de comandos que gerem o melhor desempenho de execução possível.
Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre
unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado
milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos
aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar
de atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste de
unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por
sua vez conhecem bem o código fonte produzido.
Caixa-preta
Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia
o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo.[4]
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado
previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos
derivados da especificação.
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam
testadas, mas na ampla maioria dos casos isso é impossível.[5] Outro problema é que a especificação pode estar
ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas
aceitas para o teste.[6] Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de
entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas
similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo
o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode
gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema,
pode-se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do
20
Teste de software
sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o
maior inteiro, o menor inteiro.
Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema e teste de
aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de
teste). A aplicação combinada de outra técnica – técnica de particionamento de equivalência (ou uso de classes de
equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de
equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas
classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.
Uma abordagem no desenvolvimento do teste de caixa-preta é o teste baseado na especificação, de forma que as
funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente para
identificar certos riscos num projeto de software.[7]
Caixa-cinza
A técnica de teste de caixa-cinza é um mesclado do uso das técnicas de caixa-preta e de caixa-branca. Isso envolve
ter acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os caso de teste, que são
executados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é considerado
caixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso de
engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens de
erro.
Regressão
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo
de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada
ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse
contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova
versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a
utilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes
anteriores possam ser executados novamente com maior agilidade.
Técnicas não funcionais
Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo de acordo com
necessidades de negócio ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, que
verificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam a
operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a
tolerância e a robustez do software em lidar com o inesperado.
Uma delas é o uso conjunto de teste de desempenho e teste de carga, que verifica se o software consegue processar
grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina a
escalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é fácil de se
aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, a
compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.[8] Já o teste de
confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados e
processados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável de
execução após estar em um estado de falha.
21
Teste de software
22
Fases
Abstração do teste
Descendente
Sistema
Integração
Ascendente
Unidade
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no
cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser
usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o teste
no mesmo momento que o projeto, num processo contínuo até o fim do projeto.
Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o
modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro, por
engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito,
passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do
código fonte do software, e geralmente também integra o processo de construção do software.
Teste de unidade
Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de
software desenvolvidas (pequenas partes ou unidades do sistema).[9] O universo alvo desse tipo de teste são as
subrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro
de uma pequena parte do sistema funcionando independentemente do todo.
Teste de integração
Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de
um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente A
pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar
um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros
sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do
gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.
Teste de sistema
Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as
funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições
similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-dia
de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais de
ambiente, interfaces sistêmicas e massas de dados.
Teste de aceitação
Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulam
operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste
formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente
determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte,
com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de
recuperação de falhas, de segurança e de desempenho.
Teste de software
Teste de operação
Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará em
ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma
organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem ser
feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de
instalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará em
produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.
Testes alfa e beta
Em casos especiais de processos de desenvolvimento de software – sistemas operacionais, sistemas gerenciadores de
bancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fases
também especiais antes do produto ser disponibilizado a todos os usuários.
O período entre o término do desenvolvimento e a entrega é conhecido como fase alfa e os testes executados nesse
período, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente do
desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.
Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema
denominadas versões beta. Ele também é um teste de aceitação voltado para softwares cuja distribuição atingirá
grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é
conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o
desenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação do software num
ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou
imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o
resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se
preparam para liberar o produto de software para toda a base de clientes.
A comunidade do teste de software usa o termo teste gama de forma sarcástica referindo-se aos produtos que são mal
testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de produção.
Candidato a lançamento
Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo candidato a lançamento
(release candidate) para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros
encontradas. Tais versões são um passo além do teste beta, sendo divulgadas para toda a comunidade.
Papéis
Segue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoa
pode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos de
desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, por
exemplo, os papéis de arquiteto de teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto;
o papel de testador pode ser assumido pelo programador ou por um segundo programador que atue num processo de
programação em pares. Na fase de teste de sistema, num contexto em que haja uma equipe de teste independente,
pode haver profissionais acumulando os papéis de arquiteto de teste, analista de teste e testador.
O líder (ou gerente) do projeto de testes é a pessoa responsável pela liderança de um projeto de teste específico,
normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção. Já o
engenheiro (ou arquiteto) de teste é o técnico responsável pelo levantamento de necessidades relacionadas à
montagem da infraestrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições
tecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pela
comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).
23
Teste de software
O analista de teste é o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações do
gerente de teste ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de teste
necessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada. Também no
campo de análise, o analista de ambiente é o técnico responsável pela configuração do ambiente de teste e pela
aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução e
nos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele será responsável por tornar
disponível o ambiente de teste.
O testador é o técnico responsável pela execução de teste. Ele deve observar as condições de teste e respectivos
passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuções
de teste mal-sucedidas, esse profissional pode também registrar ocorrências de teste (na maioria das vezes, defeitos)
em canais através dos quais os desenvolvedores tomarão conhecimento das mesmas e tomarão as providências de
correção ou de esclarecimentos.
Por fim, o automatizador de teste é o técnico responsável pela automação de situações de teste em ferramentas. Ele
deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a
execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execução
de ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciais
do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)
Artefatos
O processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de uma
referência a um identificador ou requisito de uma especificação, pré-condições, eventos, uma série de passos a se
seguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado obtido. A série de passos (ou parte
dela) pode estar contida num procedimento separado, para que possa ser compartilhada por mais de caso de teste.
Um script de teste é a combinação de um caso de teste, um procedimento de teste e os dados do teste. Uma coleção
de casos de teste é chamada de suite de teste. Geralmente, ela também contém instruções detalhadas ou objetivos
para cada coleção de casos de teste, além de uma seção para descrição da configuração do sistema usado.
A especificação de teste é chamada plano de teste.
[1] MYERS, 2004, p. 8
[2] MYERS, 2004, p. 5
[3] Michael Newman (28 de junho de 2002). Software Errors Cost U.S. Economy $59.5 Billion Annually: NIST Assesses Technical Needs of
Industry to Improve Software-Testing (http:/ / www. nist. gov/ public_affairs/ releases/ n02-10. htm) (em inglês). NIST. Página visitada em 17
de novembro de 2008.
[4] MYERS, 2004, p. 9
[5] MYERS, 2004, p. 10
[6] Jiantao Pan (1999). Software Testing (http:/ / www. ece. cmu. edu/ ~koopman/ des_s99/ sw_testing/ ) (em inglês). Universidade Carnegie
Mellon. Página visitada em 1 de dezembro de 2008.
[7] James Bach (Junho de 1999). Risk and Requirements-Based Testing (http:/ / www. satisfice. com/ articles/ requirements_based_testing. pdf)
(em inglês). IEEE. Página visitada em 17 de novembro de 2008.
[8] MYERS, 2004, p. 136
[9] MYERS, 2004, p. 91
24
Teste de software
25
Bibliografia
• KOSCIANSKI, A., Soares, Novatec, M. S. Qualidade de Software, 2006
• PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002
• RIOS, E., BASTOS, A., CRISTALLI, R., MOREIRA, T., Martins Fontes, Base de conhecimento em teste de
software, 2007
• MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jérsei: 2004. ISBN ISBN
0-471-46912-2
Ver também
•
•
•
•
•
Anexo:Lista de instituições pela qualidade
Gestão da qualidade
Verificação formal
Otimização em engenharia de software.
Ligações externas
• Guia de gerenciamento de teste (http://www.ruleworks.co.uk/testguide)
Gerência de Configuração de Software, Gerência de Configuração ou ainda Gestão de Configuração de
Software é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento de
software. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria das
configurações.
Roger Pressman, em seu livro Software Engineering: A Practitioner's Approach, afirma que a gerência de
configuração de software (GCS) é o:
conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados,
estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes
produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.
— Roger
Pressman
Em outras palavras, a Gerência de Configuração de Software tem como objetivo responder as seguintes perguntas:
•
•
•
•
O que mudou e quando?
Por que mudou?
Quem fez a mudança?
Podemos reproduzir esta mudança?
Cada uma dessas perguntas corresponde a uma das atividades realizadas pela Gerência de Configuração de Software.
O controle de versão é capaz de dizer o que mudou e quando mudou. O controle de mudanças é capaz de atribuir os
motivos a cada uma das mudanças. A Auditoria por sua vez responde as duas últimas perguntas: Quem fez a
mudança e podemos reproduzir a mudança?
Histórico
A história da Gerência de Configuração de Software surge em meados da década de 1970, quando os
microprocessadores se tornaram populares e o software deixou de ser considerado parte integrante do hardware para
se tornar um produto independente. Nesta época, os sistemas se tornaram cada vez maiores e sofisticados, ficando
claro que seriam necessárias metodologias próprias, diferentes das usadas no desenvolvimento de hardware, para
controlar o desenvolvimento desses sistemas.
O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa área, criando o padrão DoD-STD-2167 que
abordava o desenvolvimento de software. A abordagem do DoD para controlar isto consistia da adoção de uma
linguagem padronizada -- Ada -- e de práticas padrão para desenvolvimento de software e Gerência de Configuração.
Outras organizações estavam por sua vez adotando práticas e métodos de Gerência de Configuração de Software,
algumas das quais envolvidas também com o desenvolvimento de sistemas para o DoD e outros órgãos do governo
Americano. Isto levou o próprio DoD a adotar algumas práticas comerciais e eventualmente uni-las com seus
padrões, gerando assim o padrão IEEE/IEA 12207. Um outro padrão a respeito é o IEEE 828-1983.
Funções
A Gerência de Configuração de Software é definida por quatro funções básicas:[1]
•
•
•
•
Identificação
Documentação
Controle
Auditoria
No início do desenvolvimento, a GCS permite à equipe de desenvolvimento identificar as unidades que compõem o
sistema de acordo com as funcionalidades que elas deverão desempenhar, e as interfaces entre estas unidades,
documentando assim a interação entre elas. O controle contínuo da evolução destas funcionalidades e interfaces
permite que a integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente gerenciadas
e documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante a
confiabilidade do sistema.
Conceitos e Terminologia
A terminologia especifica da GCS, como também sua história, tem dado origem a controvérsias, de freqüentes
variações. Ferramentas vendidas como também acadêmicas tiraram vantagem disto para deliberadamente mudar a
terminologia ou procedimentos para reduzir a possibilidade dos clientes para mudanças, algumas vezes tentando
desta maneira redefinir o estabelecimento de acrônimos.
Em particular, o vendedor conhecido como Atria (depois Rational Software), agora uma parte da IBM, usava SCM
como padrão para Software Configuration Management (em português: "Gerência de Configuração de Software")
enquanto o Gartner Group usa o termo SCCM ou Software Change and Configuration Management (em português:
"Gerência de Mudanças e Configuração de Software").
Entretanto, os conceitos básicos da GCS descritos abaixo são bem aceitos, divergindo de um autor ou fornecedor
para o outro meramente nos termos utilizados.
26
Configuração de software
Configuração é o estado em que um sistema se encontra em um determinado momento. Este sistema pode ser
composto de todo tipo de elementos, como peças de hardware, artefatos eletrônicos ou não (i.e. documentos em
papel), etc. A Configuração de Software trata apenas dos elementos que se encontram em formato eletrônico e
fazem parte dessa configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, as
ferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, as
bibliotecas de software, etc.
Essa configuração varia com o tempo, pois novos arquivos são incluídos, e arquivos existentes são alterados ou
removidos. O objetivo da Gerência de Configuração como um todo é organizar todos estes elementos de forma a
saber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento (por exemplo, quando o
sistema foi entregue ao cliente, quando o sistema passou por uma mudança de versão, quando o sistema foi enviado
para auditoria, etc). A Gerência de Configuração como um todo trata dos elementos, incluindo hardware, necessários
para a manutenção apropriada do sistema. a Gestão de Configuração de Software trata especificamente dos
elementos necessários a construção de sistemas de software, e em geral, controla apenas os elementos em formato
computadorizado.
Em Sistemas de controle de versão as configurações específicas são geralmente identificadas pelo uso de tags ou
labels (placas ou etiquetas, em inglês).
Linha-base
Linhas-base ou Baseline é um conceito de gerenciamento de configuração de software que nos ajuda a controlar as
mudanças, sem impedir seriamente as mudanças justificáveis. Segundo PRESSMAN no contexto de engenharia de
software, definimos uma linha básica como um marco de referência no desenvolvimento de um software, que é
caracterizado pela entrega de um ou mais itens de configuração (em inglês, Software Configuration Items - SCIs) e
pela aprovação desses SCIs, obtida por meio de uma revisão técnica formal.
Exemplos de linhas-base:
• Versão 1.0
• Versão de correção de erros 1.1
• Versão personalizada do sistema para o governo americano
Em Sistemas de controle de versão uma linha-base é geralmente identificada pelo uso de branches (galhos, em
inglês).
Item de configuração de software
Durante o desenvolvimento de software, uma grande quantidade de informações é produzida e cada um desses
documentos produzidos que precisam sofrer controle de versões e de mudanças é chamado de item de configuração
de software O Item de configuração é um elemento unitário que será gerenciado: um arquivo de código fonte, um
documento de texto, um projeto de uma placa eletrônica, uma planta feita em papel, um CD-ROM de instalação de
um sistema operacional, etc. A configuração de um sistema é basicamente a lista de todos os itens de configuração
necessários para reproduzir um determinado estado de um sistema. Em geral números de versão são associados aos
itens de configuração de forma a podermos identificar também a evolução destes itens.
Exemplos de itens de configuração podem ser:
• Item A: CD de instalação do sistema operacional, versão 1.0
• Item B: Documento de ajuda do sistema em formato eletrônico, versão 2.0
• Item C: Processador de texto usado para imprimir o documento de ajuda, versão 5.0
e assim por diante.
27
Segundo Pressman os seguintes SCIs tornam-se alvos das técnicas de GCS e formam um conjunto de linhas básicas
(Baselines):
1. Especificação do Sistema.
2. Plano de Projeto do Software.
3. a) Especificação dos Requisitos de Software; b) Protótipo executável ou "em papel".
4. Manual Preliminar do Usuário.
5. Especificação de Projeto: a) Descrição do projeto de dados; b) Descrições do projeto arquitetural; c) Descrições do
projeto modular; d) Descrições do projeto de interfaces; e) Descrições de objetos (no caso do uso da metodologia
OO).
6. Listagem do código-fonte.
7. Teste de Software/Sistema: a) Plano e Procedimentos de Testes; b) Casos de teste e resultados registrados.
8. Manuais Operacionais e de Instalação.
9. Programa Executável: a) Módulos; b) Módulos interligados.
10. Descrição do Banco de Dados: a) Esquema e estrutura de arquivo; b) Conteúdo inicial.
11. Manual Feito de Acordo com o Usuário.
12. Documentos de Manutenção: a) Relatórios de problemas de software; b) Solicitações de manutenção; c) Pedidos
de mudança de engenharia.
13. Padrões e procedimentos para engenharia de software.
Identificação de objetos
Definimos CSI, no mecanismo de identificação de gerenciamento de configurações, como sendo a sua entidade mais
elementar.
Segundo PRESSMAN dois tipos de objetos podem ser identificados:
• Objeto básico: uma "unidade de texto" que foi criada pelo engenheiro de software durante a análise, o projeto, a
codificação ou o teste.
• Objeto composto: coleção de objetos básicos e outros objetos compostos.
Cada objeto tem um conjunto distinto de características que o identifica unicamente: um nome, uma descrição, uma
lista de recursos e uma realização.
• Nome: cadeia de caracteres que identifica o objeto claramente.
• Descrição: é uma lista de itens de dados que identifica: - O tipo de SCI (ex.: documento, programa, dados) que é
representado pelo objeto; - Um identificador do projeto; - Informações sobre mudanças e/ou versão
• Recursos: entidades fornecidas, processadas, consultadas ou, por outro lado, exigidas pelo objeto.
Para um objeto básico, a realização é um indicador para a "unidade texto" e para o objeto composto a realização é
nula.
28
Controle de versões
Ocorrem muitos problemas durante o desenvolvimento de software que são causados por falta de controle sobre os
arquivos do projeto.
Vamos a uma avaliação:
•
•
•
•
Você já perdeu alguma versão anterior do arquivo do projeto?
Já teve problemas em manter diferentes versões do sistema rodando ao mesmo tempo?
Alguém já sobrescreveu o seu código por acidente e você acabou perdendo seu arquivo?
Você tem dificuldades em saber quais as alterações que foram efetuadas e quando foram feitas e quem fez?
Se você respondeu que sim para as perguntas acima, então você precisa de um sistema para controle de versão para o
seu projeto. Controle de versão deve ser utilizado em todo o andamento do projeto de desenvolvimento de software.
O Controle de versão rastreia e controla todos os artefatos do projeto (código-fonte, arquivos de configuração,
documentação etc.) e assim consegue coordenar o trabalho paralelo de desenvolvedores através das seguintes
funcionalidades:
• Mantém e disponibiliza cada versão já produzida de cada item do projeto
• Possui mecanismos para gerenciar diferentes ramos de desenvolvimento, possibilitando a existência de diferentes
versões ao mesmo tempo (concorrência)
• Estabelece uma política de sincronização de mudanças que evita a sobreposição de mudanças
• Fornece um histórico completo de alterações sobre cada item do projeto
Controle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões de
código, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriores
e registro do histórico de alterações.
A finalidade do Controle de versão é dar um controle maior sobre tudo que você altera no seu projeto de software.
Ele permite que você tenha um histórico de tudo o que você mudar no seu projeto. Se você modificou aquela rotina
para otimizar uma consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que era
exibida em determinada página html, tudo fica guardado neste histórico. Para que isso? Para o caso de sua alteração
causar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudo
correto, basta um simples comando e você recupera o estado anterior.
Controle de versões dos itens do projeto
Todos os arquivos e diretórios que compõem o projeto ficam sob a responsabilidade do sistema de controle de versão
num local denominado de repositório, lugar onde se guarda, arquiva, coleciona alguma coisa. É o local onde você vai
guardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seu
pendrive. O repositório registra cada alteração realizada em cada arquivo e diretório controlado. À medida que o
projeto evolui, o repositório passa a guardar múltiplas versões dos arquivos que compõem o projeto. Essas múltiplas
versões são organizadas em revisões. Uma revisão funciona como um clone de todos os arquivos do projeto em um
determinado momento do tempo. Os clone antigos são mantidos e podem ser recuperados e analisados a qualquer
momento. Para economizar espaço, apenas as diferenças entre as revisões costumam ser armazenadas no repositório.
Quando se deseja recuperar determinado arquivo, as diferenças são analisadas e o arquivo é remontado de acordo
com a revisão desejada. Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número da
revisão do arquivo acompanha o número da revisão global, de modo a manter sempre um grupo coeso e coerente de
arquivos.
29
Diferentes versões de projeto
Alguns projetos precisam de variações específicas, conforme as necessidades específicas de cada cliente, ou criação
de um ramo para experimentações no projeto, sem comprometer a linha principal de desenvolvimento. O sistema de
controle de versão oferece funcionalidades que facilitam a coordenação de ramos diferentes de desenvolvimento em
um mesmo projeto. As alterações feitas em um ramo muitas vezes precisam ser mescladas em outro ramo. Essa
operação é bastante delicada e é facilitada em muito com o sistema de controle de versão, que permite bastante
controle e automação no processo. Mesmo em caso de uma fusão mal-sucedida, o sistema de controle de versão
permite voltar ao estado anterior, o que traz bastante segurança aos desenvolvedores.
Sincronização de Mudanças Concorrentes
Como os desenvolvedores trabalham em paralelo e concorrentemente nos mesmos arquivos do projeto, é necessária
uma política para ordenar e integrar todas essas alterações, de modo a evitar que um desenvolvedor sobrescreva as
alterações de outro desenvolvedor.
O controle de versão além de rastrear e controlar alterações, também coordena a edição colaborativa e o
compartilhamento de dados entre os vários desenvolvedores de uma equipe.
Problema do Compartilhamento de Arquivos
Cópia de Trabalho
Os desenvolvedores não trabalham diretamente nos arquivos do repositório. Cada desenvolvedor possui uma cópia
de trabalho que espelha os arquivos do repositório para trabalhar com liberdade enquanto termina suas tarefas,
isolado dos outros desenvolvedores.
Política TRAVA-MODIFICA-DESTRAVA
Nessa política, o sistema de controle de versão permite que apenas um desenvolvedor por vez altere um determinado
arquivo do projeto. Ela é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causar
alguns problemas administrativos e forçar a uma serialização desnecessária.
Política COPIA-MODIFICA-RESOLVE
Nessa política, não existe travamento de arquivos. Cada desenvolvedor trabalha livremente em qualquer arquivo da
sua cópia de trabalho. Ao final, as alterações de cada desenvolvedor são mescladas no repositório formando a versão
final. A solução "copia-modifica-resolve" parece um pouco estranha e bagunçada a princípio, mas funciona bem na
prática. Conflitos são raros e são causados basicamente pela falta de comunicação entre desenvolvedores. Na grande
maioria dos casos, as alterações não se sobrepõe e são mescladas automaticamente pelo sistema de controle de
versão.
Conjunto de mudanças
É o conjunto de todas as alterações que ocorreram no sistema para atender um determinado fim, ou num determinado
período de tempo. Fazendo um mapeamento dos itens que foram mudados para uma dada versão do sistema com os
motivos das mudanças. Um exemplo de conjunto de mudanças:
Mudanças da versão 1.0 para a versão 1.1
•
•
•
•
•
Item A mudou da revisão 1.0 para a revisão 1.1
Item B mudou da revisão 4.5 para a revisão 5.0
Item C foi eliminado
Item D foi acrescentado na revisão 5.5
Item E mudou de nome para item F.
30
Gerência de mudanças
A Gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não tem
resultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por não
perceber sua importância. Gerência de mudanças entretanto é uma parte importante da Gerência de configuração,
pois é a atividade que permite se saber o motivo de uma configuração ter sido mudada para outra configuração. Esta
atividade também pode ser parcialmente automatizada, e diversos Sistemas de controle de versão já são integrados
com sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudança
efetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivos
que listam as melhorias e mudanças entre duas versões. Estes arquivos são resultado da gerência de mudanças,
identificando o que mudou entre uma versão e outra.
Exemplos
• mudança da versão 1.0 para 1.1 inclui:
•
•
•
•
correção do problema 355
nova funcionalidade de impressão de relatórios
• pendências para a versão 1.2:
• correção das mudanças 357 e 359.
• impressão de relatórios coloridos.
Histórico de Alterações
Como o repositório registra todas as alterações que foram efetuadas, o sistema de controle de versão pode informar
com facilidade quais as alterações que foram realizadas entre uma revisão e outra, quando isso ocorreu e quem fez as
alterações. Essas informações permitem um controle maior sobre mudanças no projeto.
Auditoria de configuração
Executar Auditoria de Configuração Física
Uma Auditoria de Configuração Física (PCA) identifica os componentes de um produto que serão implantados do
Repositório do Projeto. Os passos são:
• Identificar a baseline a ser implantada (geralmente é apenas um nome e/ou número, mas também pode ser uma
lista completa de todos os componentes e suas respectivas versões).
• Confirmar que todos os artefatos necessários, conforme especificado pelo Caso de Desenvolvimento, estão
presentes na baseline. Liste os artefatos ausentes em Descobertas da Auditoria de Configuração.
Outros Níveis da Auditoria de Configuração Física
Algumas organizações usam uma Auditoria de Configuração Física para confirmar a consistência do design e/ou
documentação do usuário com o código. O Rational Unified Process recomenda que a verificação dessa consistência
seja executada como parte da atividade de revisão no decorrer do processo de desenvolvimento. No último estágio,
as auditorias devem se limitar a verificar os produtos liberados necessários que estão presentes, sem se preocupar em
revisar o conteúdo.
31
Executar Auditoria de Configuração Funcional
Uma Auditoria de Configuração Funcional (FCA) confirma que uma baseline atende aos requisitos estabelecidos
para ela. Os passos para a execução dessa auditoria são:
• Preparar um relatório que liste cada requisito estabelecido para a baseline, seu procedimento de teste
correspondente e o resultado de teste (aprovado/reprovado) da baseline.
• Confirmar que cada requisito passou por um ou mais testes e que o resultado de todos esses testes foi 'aprovado'.
Em Descobertas da Auditoria de Configuração, liste quaisquer requisitos que não tenham passado por
procedimentos de teste e os requisitos que estão com teste incompleto ou que foram reprovados.
• Gerar uma lista das CRs estabelecidas para essa baseline. Confirme que cada CR foi fechada. Em Descobertas da
Auditoria de Configuração, liste quaisquer CRs que não estão fechadas.
Reportar Descobertas
Se houver alguma discrepância, ela será capturada em Descobertas da Auditoria de Configuração conforme descrito
anteriormente. Além disso, os seguintes passos deverão ser executados:
• Identificar ações corretivas. Talvez, isso requeira a entrevista de vários membros da equipe do projeto para que a
origem da discrepância e as ações apropriadas sejam identificadas.
• Para artefatos ausentes, a ação apropriada é geralmente controlar a configuração do artefato ou criar uma CR ou
tarefa que produzirá o artefato ausente.
• No caso de requisitos não testados ou reprovados no teste, o requisito pode ser estabelecido para uma baseline
posterior ou negociado para ser removido do conjunto de requisitos.
• Para CRs em aberto, a CR pode ser simplesmente fechada, testada ou adiada para uma baseline posterior.
• Para cada ação corretiva, atribua uma responsabilidade e determine uma data de conclusão.
Política de Gerência de Configuração de Software
A finalidade da política de Gerência de Configuração de Software consiste em definir a maneira como as atividades
de Gerência de Configuração de Software serão executadas, o momento adequado, os responsáveis em executa-las e
os conceitos envolvidos no processo. Entre as definições que devem contar nas políticas de Gerência de configuração
de software podemos citar:
• Ferramentas para automatização do controle de revisões (Sistema de controle de versão) caso seja usada.
• Caso não seja usada ferramenta, deve se definir o procedimento manual para o controle de revisões.
• Caso existam elementos que não estejam em formato eletrônico (ferramentas de hardware por exemplo), os
procedimentos de controle de revisões para estes elementos deve também ser definido.
• Ferramentas para o controle de mudanças
• Caso não seja usada ferramenta, deve também ser definido o procedimento manual.
• Controle de acesso às ferramentas de controle de revisão e controle de mudanças
• Nível de integração entre as ferramentas caso sejam ferramentas distintas
• Alguns fabricantes fornecem ferramentas que já desempenham os papeis de controle de revisão e controle de
mudanças num único sistema, enquanto outros fabricantes as fornecem em separado.
• Periodicidade e granularidade do controle de revisões
• Recomenda-se um controle diário para elementos em formato eletrônico. A granularidade em geral depende do
tipo de item e da ferramenta utilizada.
• Papeis a serem desempenhados pelos membros da equipe dentro do contexto de Gerência de Configuração de
Software.
• Freqüência e forma de realização das auditorias de configuração.
32
• Em geral apenas a primeira auditoria de configuração de uma linha-base precisa de intervenção humana, sendo
que as auditorias subseqüentes apenas verificam se houve quebra da integridade dos arquivos auditados.
Papéis
Uma das principais definições da política de Gerência de Configuração de Software são os papeis a serem
desempenhados. A política não determina quais pessoas desempenharão quais papeis, cabendo isso a gerência de
projeto. Alguns papeis necessários numa política são:
• Gestor de configuração do projeto. Ele é o responsável por acompanhar as alterações dos itens de configurações
de um determinado projeto. Em geral este papel cabe ao integrador.
• Gestor de ferramentas de Gerência de configuração. Ele é o responsável pela manutenção da infra-estrutura
necessária para o bom funcionamento da Gerência de configuração no conjunto dos projetos da organização, ou
no contexto do projeto, se for o caso. Em geral é uma pessoa da área de infra-estrutura com bons conhecimentos
da plataforma operacional e das ferramentas usadas.
• Gestor de Configuração de Software, ou Responsável de Gerência de Configuração de Software. Ele é o
responsável por aprovar e gerenciar as atividades relativas a Gerência de Configuração de Software, coordenar a
equipe de Gerência de Configuração de Software e algumas vezes, coordenar o trabalho de integração de
sistemas.
• Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias de configuração nos
projetos.
• Desenvolvedor. Ele é o principal usuário da Gerência de configuração de software, sendo quem produz os itens de
configuração que serão gerenciados.
[1] BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova Iorque: Wiley computer publishing,
1999. 0-471-32929-0
Bibliografia
• BROWN, William J. et ali. Antipatterns and Patterns in Software Configuration Management. Nova
Iorque: Wiley computer publishing, 1999. 0-471-32929-0
• MIKKELSEN, Tim, PHERIGO, Suzanne. Parctical Software Configuration Management: The Latenight
Developer's Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR, 1997. 0-13-240854-6
• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5
• PRESSMAN, Roger S.. Engenharia de Software. São Paulo: Pearson Makron Books, 1995. 85-346-0237-9
Ver também
• Sistema de controle de versão
Ligações externas
• Gerência de Configuração (http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/
gerencia_configuracao.php?pagNum=1) (em português)
33
Definição
Um processo de Engenharia de Software é formado por um conjunto de passos de processo parcialmente ordenados,
relacionados com artefatos, pessoas, recursos, estruturas organizacionais e restrições, tendo como objetivo produzir e
manter os produtos de software finais requeridos.
Conceitos
Os processos são divididos em atividades ou tarefas. Uma atividade é um passo de processo que produz mudanças de
estado visíveis externamente no produto de software. Atividades incorporam e implementam procedimentos, regras e
políticas, e têm como objetivo gerar ou modificar um dado conjunto de artefatos.
Um artefato é um produto criado ou modificado durante um processo. Tal produto é resultado de uma atividade e
pode ser utilizado posteriormente como matéria prima para a mesma ou para outra atividade a fim de gerar novos
produtos.
Uma atividade aloca recursos (por exemplo, computadores, impressoras e material de expediente), é escalonada,
monitorada e atribuída a desenvolvedores (agentes), que podem utilizar ferramentas para executá-la.
Toda atividade possui uma descrição, a qual pode especificar os artefatos necessários, as relações de dependência
com outras atividades, as datas de início e fim planejadas, os recursos a serem alocados e os agentes responsáveis
pela mesma.
O agente pode ser uma pessoa ou uma ferramenta automatizada (quando a atividade é automática) e relaciona-se
com as atividades de um processo. Os agentes podem estar organizados em cargos, aos quais podem ser definidas
diferentes responsabilidades.
A realização do processo é afetada pelas restrições, que podem atingir atividades, agentes, recursos, artefatos, papéis
e seus relacionamentos. Uma restrição é uma condição definida que um passo de processo deve satisfazer antes ou
depois de ser executado.
34
Atividade de Processos de Engenharia de Software e seus inter-relacionamentos
Bibliografia
Reis, Rodrigo Quites et. al. 2002. Automação no Gerenciamento do Processo de Engenharia de Software.
Disponível em [1];
Ver também
• Administração de dados
Referências
[1] http:/ / www. labes. ufpa. br/ quites/ teaching/ 2006/ TopicosES/ ProcessoEngenhariaSoftware. pdf
35
A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade
do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na
garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto
final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente.
Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um conjunto de características inerentes a
um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para estes.
No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de
desenvolvimento[1] , desta forma, é comum que a busca por um software de maior qualidade passe necessariamente
por uma melhoria no processo de desenvolvimento.
Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da Computação do MIT, define qualidade
como a conformidade aos requisitos. Essa definição exige determinar dois pontos: I) o que se entende por
conformidade; e II) como são especificados - e por quem - os requisitos.
Principais tópicos
Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de software em três tópicos, e cada tópico é
subdividido em atividades, da seguinte forma:
• Fundamentos de qualidade de software
• Cultura e ética de engenharia de software
• Valores e custos de qualidade
• Modelos e características de qualidade
• Melhoria da qualidade
• Gerência do processo de qualidade de software
• Garantia de qualidade de software
• Verificação e validação
• Revisões e auditorias
• Considerações práticas
•
•
•
•
Requisitos de qualidade para aplicações
Caracterização de defeitos
Técnicas de gerência de qualidade de software
Medidas de qualidade de software
Ainda segundo o SWEBOK, a qualidade de software é um tema tão importante que é encontrado, de forma ubíqua,
em todas as outras áreas de conhecimento envolvidas em um projeto. Além disso, ele deixa claro que essa área,
como nele definida, trata do aspectos estáticos, ou seja, daqueles que não exigem a execução do software para
avaliá-lo, em contraposição á área de conhecimento teste de software.
Porém, é normal que se encontrem autores e empresas que afirmam serem os testes de software uma etapa da
qualidade de software.
Muita coisa pode ser encontrada no site http:/ / www. ibqts. com. br O IBQTS, Instituto Brasileiro de Qualidade em
Testes de Software
36
Requisitos de qualidade
Requisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se que
os requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído. Nesse aspecto - e
em relação à definição de Brooks - é evidente que as zonas de sombra dentro de uma especificação abrem margem a
todo tipo de problemas de avaliação de produtos.
Sommerville distingue requisitos funcionais e não funcionais. O modelo internacional mais recente Square,
estabelecido pela norma ISO 25000, adota uma classificação um pouco diferente e utiliza uma descrição hierárquica.
Dentro dessa descrição, "funcionalidade" é uma das seis divisões iniciais em que se classificam os requisitos de um
produto de software.
Idealmente, a especificação de requisitos deve permitir que o processo de fabricação do software seja controlado.
Isso significa que idealmente a qualidade de produtos intermediários deve poder ser mensurada e que os dados
obtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrências
negativas.
O processo de software
Nas últimas décadas foram propostas dezenas de metodologias e processos adaptados a diferentes cenários e
produtos. Embora se possa justificar essa multiplicidade por outra lei de Brooks - a ausência de "balas de prata", é
um fato que a situação se mostra confusa.
Há dezenas de trabalhos propostos para casos particulares. Exemplos das diversas iniciativas para tratar o assunto
são metodologias como XP e Scrum; o modelo CMM, seguido de toda uma série de adaptações (como SW-CMM,
people-CMM, etc.), mais tarde substituído pelo modelo CMMI; e dezenas de artigos e teses de mestrado e
doutorado, abordando tópicos particulares em um ou mais de tais métodos, ou propondo ainda novas adaptações a
casos particulares.
A situação deixa evidente que há um vácuo a ser preenchido - atacar a raiz do problema e identificar uma estrutura
suficientemente geral, capaz de explicar o problema de qualidade e ser adaptada a todos os cenários diferentes. Se tal
objetivo é possível resta a ser provado - assunto para novos artigos e teses.
Garantia de qualidade de software
A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários
níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A
GQS atua como "guardiã", fornecendo um retrato do uso do Processo e não é responsável por executar testes de
software ou inspeção em artefatos.
Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes
objetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, ter
alta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e não
necessitar de recursos adicionais não previstos.
Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelo
desenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-se
destacar:
• o planejamento do projeto e o acompanhamento de resultados;
• o uso dos métodos e ferramentas padronizadas na organização;
• a adoção de Revisões Técnicas Formais;
• o estabelecimento e a monitoração de estratégias de testes;
• a revisão dos artefatos produzidos pelo processo de desenvolvimento;
37
• a busca de conformidade com os padrões de desenvolvimento de software;
• a implantação de medições associadas a projeto, processo e produto;
• a utilização de mecanismos adequados de armazenamento e recuperação de dados relativos a projetos, processos e
produtos; e
• a busca de uma melhoria contínua no processo de desenvolvimento de software.
Para facilitar o trabalho dos desenvolvedores e evitar geração de metodologias diversas, o Serpro desenvolveu o
Processo Serpro de Desenvolvimento de Soluções (PSDS).
O PSDS foi construído por pessoas das unidades da empresa que procuraram aproveitar as melhores práticas
existentes e consagradas.
O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura-"framework", que descreve os principais
elementos de um processo de desenvolvimento de software efetivo. O CMM descreve os estágios de maturidade
através dos quais Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua
avaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Este
caminho de melhoria é definido por cinco níveis de maturidade: inicial, repetitivo, definido, gerenciado e otimizado.
O Modelo CMM (CMM- Capability Maturity Model) fornece às organizações uma direção sobre como ganhar
controle de seu processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestão
de software. O objetivo principal nas transações destes níveis de maturidade é a realização de um processo
controlado e mensurado como a fundação para melhoria contínua. Cada nível de maturidade possui um conjunto de
práticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para a
organização atingir o nível de maturidade em qualidade de software.
Bibliografia
1. AROUCK, O. Avaliação de sistemas de informação: revisão da literatura [2]. Transinformação, v. 13, n. 1,
jan./jun., 2001. p. 7-21.
2. BROOKS, F. P. No Silver Bullet: Essence and Accidents of Software Engineering". Computer, Vol. 20, N. 4, pp
10-19. April, 1987.
3. KOSCIANSKI, A., Soares, M. S.. Qualidade de Software. Editora Novatec, Segunda Edição, 2007.
4. MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software,
Editora Visual Books, 2007, Florianópolis, 85-7502-210-5.
5. MOLINARI, Leonardo. Testes de Software - Produzindo Sistemas Melhores e Mais Confiáveis, Editora Èrica,
2006, 3a Edição, São Paulo, 85-7194-959X.
6. PRESSMAN, R. S. Engenharia de Software. McGraw Hill, 2002.
Modelos de qualidade
• CMMI
• MPS.BR
• ISO 9126
Ver também
• Lista de instituições pela qualidade
• Teste de software
• Teste de unidade
• Gestão da qualidade
• ISO
• BIA
38
• Underwriters Laboratories
[1] Qualidade de Software: Visões de Produto e Processo de Software (http:/ / www. prodepa. psi. br/ sqp/ pdf/ Qualidade de Software. pdf)
[2] http:/ / www. eci. ufmg. br/ bogliolo/ downloads/ AROUK%20Avaliacao%20de%20sistemas%20de%20informacao. pdf
Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para o concretizar,
mas é também importante perceber como as actividades do processo se relacionam umas com as outras para que se
torne visível todo o processo de desenvolvimento. O termo modelo do ciclo de vida é utilizado para descrever um
modelo que visa descrever um grupo de actividades e a forma como elas se relacionam. Os modelos mais
sofisticados incluem ainda uma descrição de quando e como se deve mover de uma actividade para a próxima e os
deliverables que devem ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos é o facto
ajudarem as equipas de desenvolvimento, e em particular os gestores, a obter uma visão geral do projecto de forma a
ser possível segui-lo passo a passo, saber que deliverables foram especificados, o alocamento de recursos e os
objectivos propostos. Estes "modelos de ciclo de vida" ou "modelos de processos" são tipicamente produzidos a
partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz de
dar uma visão completa de um determinado processo.
Modelos de Processos
Embora este artigo seja mais focado aos modelos de ciclo de vida na engenharia de requisitos de projetos de
software, é importante ter uma ideia dos vários tipos de modelos de processos existentes. Os tipos de modelos de
processos que podem ser produzidos dependem do uso que lhes será dado. Poderá ser necessário um modelo para
explicar como está organizada a informação de processos, um modelo que ajude a compreender e permita melhorar
processos, um modelo para satisfazer certos requisitos de qualidade, etc. Alguns exemplos de modelos que
descrevem processos são:
Modelos de Atividade
A figura seguinte é um exemplo deste tipo de modelo. Estes
modelos mostram os principais processos e atividades de
engenharia de requisitos e o seu sequenciamento (aproximado).
Este tipo de modelos não permite forçar um processo mas dá uma
visão geral do mesmo e são tipicamente construídos como ponto
de partida para a descrição de um processo com secções separadas
Modelo de atividades.
dando cobertura a cada caixa no modelo. Os modelos descrevem o
contexto das diferentes atividades de um processo, mostrando outros processos que consomem ou produzem input de
um outro.
39
Modelos de Atividade de Granularidade Fina
Estes são modelos mais detalhados para um processo específico. Podem ser utilizados para perceber e melhorar
processos existentes.
Modelos Papel-Ação
Estes são modelos que mostram o papel de diferentes pessoas envolvidas num processo e as ações que podem tomar.
Estes modelos, que não são tratados mais a fundo neste artigo, podem ajudar a perceber e automatizar processos.
Modelos Entidade-Relação
Estes modelos mostram as entradas, saídas e resultados intermédios dos processos e relações entre eles. Podem ser
utilizados num sistema de gestão de qualidade e como modelos complementares das actividades de processo.
Atividades do Processo de Engenharia de Requisitos
Diferentes tipos de organizações abordam a engenharia de requisitos de formas radicalmente diferentes. Uma
companhia aeroespacial que se encontre a especificar sistemas de software e hardware muito complexos não utiliza o
mesmo processo de engenharia de requisitos que uma outra companhia que desenvolve produtos de consumo para
computadores pessoais. No entanto, as diferenças entre estes processos encontram-se geralmente no nível de detalhe
dos processos. Num nível abstracto, todos os processos de engenharia de requisitos podem ser descritos pelo modelo
mostrado na figura anterior. Antes de apresentar os modelos de ciclo de vida para o processo de engenharia de
requisitos, torna-se necessário compreender melhor as actividades nele envolvidas. As actividades do processo de
engenharia de requisitos são as seguintes:
Levantamento de Requisitos
Os requisitos do sistema são obtidos através de consultas aos stakeholders, documentação do sistema, conhecimento
do domínio e estudos de mercado. Este processo é também conhecido como aquisição de requisitos ou descoberta de
requisitos.
Análise e Negociação de Requisitos
Os requisitos são analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos serão
aceitos. Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de diferentes
fontes, existência de informação incompleta ou então os requisitos podem ser incompatíveis com o orçamento
disponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade no negociamento de
requisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.
Documentação de Requisitos
Os requisitos acordados durante o processo de negociação são documentados com um nível de detalhe apropriado.
Em geral, é necessário existir um documento de especificação de requisitos que seja compreendido por todos os
stakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podem
também ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.
Validação de Requisitos
Todos os requisitos obtidos nas actividades anteriores devem ser cuidadosamente verificados para apurar se estão
completos e são consistentes. Este processo tem como finalidade detectar potenciais problemas no documento de
especificação de requisitos antes que este seja utilizado como base para o desenvolvimento do sistema.
40
Modelos de Ciclo de Vida
Os modelos existentes possuem diferentes graus de sofisticação e complexidade. Para projetos que envolvem uma
equipe de desenvolvimento pouco numerosa e experiente, o mais adequado será provavelmente um processo
simples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milhares
de utilizadores, um processo simples não é suficiente para oferecer a estrutura de gestão e disciplina necessárias à
engenharia de um bom produto de software. Desta forma, é necessário algo mais formal e disciplinado. É importante
fazer notar que isto não significa que se perca em inovação ou que se põe entraves à criatividade. Significa apenas
que é utilizado um processo bem estruturado para permitir a criação de uma base estável para a criatividade.
Por mais simples ou complexo que possa parecer, um modelo de ciclo de vida de um projeto é, de facto, uma versão
simplificada da realidade. É suposto ser uma abstracção e, tal como todas as boas abstracções, apenas a quantidade
de detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer organização que deseje por um modelo de
ciclo de vida em prática irá necessitar de adicionar detalhes específicos para dadas circunstâncias e diferentes
culturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao mesmo tempo tornar possível o
desenvolvimento de grandes e complexos produtos de software.
Na próxima secção, é introduzido uma interpretação do aspecto que um modelo de ciclo de vida deve ter em termos
de engenharia de requisitos para projectos de software. Dependendo do tipo de sistema em desenvolvimento pode
não ser completamente possível ou até apropriado seguir os modelos rigorosamente. É de notar também que para por
em prática um destes modelos e aplica-lo a um projecto real seria necessário adicionar mais detalhe.
Modelos em Engenharia de Software e Requisitos
A engenharia de software tem produzido inúmeros modelos de ciclo de vida, incluindo os modelos de cascata,
espiral e desenvolvimento rápido de aplicações (RAD). Antes do modelo de cascata ser proposto em 1970, não havia
concordância em termos dos métodos a levar a cabo no desenvolvimento de software. Desde então ao longo dos anos
muitos modelos têm sido propostos refletindo assim a grande variedade de interpretações e caminhos que podem ser
tomadas no desenvolvimento de software. Neste artigo, foi decidida a inclusão destes modelos por duas razões:
primeiro porque são representativos dos modelos utilizados na indústria e foi já provado o seu sucesso, e segundo
porque mostram como a ênfase no desenvolvimento de software mudou gradualmente de forma a incluir uma visão
mais interativa e centrada no utilizador.
Modelo em Cascata
O modelo de ciclo de vida em cascata foi o
primeiro modelo a ser conhecido em
engenharia de software e está na base de
muitos ciclos de vida utilizados hoje em dia.
Este consiste basicamente num modelo
linear em que cada passo deve ser
completado antes que o próximo passo
possa ser iniciado. Por exemplo, a análise de
requisitos deve ser completada antes que o
Modelo em Cascata.
desenho do sistema possa ser iniciado. Os
nomes dados a cada passo variam, assim como varia a definição exata de cada um deles, mas basicamente o ciclo de
vida começa com a análise de requisitos movendo-se de seguida para a fase de desenho, codificação, implementação,
teste e finalmente manutenção do sistema. Uma das grandes falhas deste modelo é o fato de os requisitos estarem
constantemente a mudar já que os negócios e ambiente em que se inserem mudam rapidamente. Isto significa que
não faz sentido parar os requisitos durante muito tempo, enquanto o desenho e implementação do sistema são
41
42
completados. Foi então reconhecido que seria necessário dar feedback às atividades iniciais a partir do momento em
que este modelo começou a ser usado em grande escala. A ideia de interacção não foi incorporada na filosofia do
modelo de cascata. Neste momento, é incluído algum nível de interação na maior parte das versões deste modelo e
são comuns sessões de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No entanto, a
possibilidade de revisão e avaliação com os utilizadores do sistema não está contemplada neste modelo.
Modelo em Espiral
Durante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, mas
em 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de software saltam
a vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativa
permitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada interação à volta da
espiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso da espiral, não foi a
necessidade do envolvimento dos utilizadores que inspirou a introdução de interação mas sim a necessidade de
identificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades
são repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. Se forem
encontrados problemas numa versão inicial do documento, reentra-se nas fases de levantamento, análise,
documentação e validação. Isto repete-se até que seja produzido um documento aceitável ou até que fatores externos,
tais como prazos e falta de recursos ditem o final do processo de engenharia de requisitos.
Características de Vários Modelos
Na tabela seguinte estão sumariadas algumas vantagens e desvantagens de vários modelos de ciclo de vida utilizados
em engenharia de requisitos para projectos de software:
Modelo
Vantagens
Desvantagens
Cascata
Minimiza o tempo de planejamento.
Funciona bem para equipes tecnicamente mais fracas.
Inflexível.
Apenas a fase final produz um deliverable que
não é um documento.
Torna-se difícil voltar atrás para corrigir erros.
Espiral
As interações inicias do projecto são as mais baratas, permitindo que as
tarefas de maior risco sejam levadas com o mínimo de custos.
Cada iteração da espiral pode ser customizada para as necessidades
específicas de cada projecto.
É complexo e requer atenção e conhecimento
especiais para o levar a cabo.
Prototipagem
Evolucionária
Os clientes conseguem ver os progressos.
É útil quando os requisitos mudam rapidamente e o cliente está
relutante em aceitar um conjunto de requisitos.
É impossível determinar com exactidão o tempo
que o projecto vai demorar.
Não há forma de saber o número de iterações que
serão necessárias.
Codificação e
Correcção
Não há tempo gasto em planejamento, documentação, gestão de
qualidade e cumprimento de standards.
Requer pouca experiência.
Perigoso.
Não há forma de assegurar qualidade e identificar
riscos.
Falhas fundamentais não percebidas
imediatamente resultando em trabalho deitado
fora.
Entre outros modelos utilizados estão: Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools
e Off-the-Shelf.
Bibliografia
• Gerald Kotonya ; Ian Sommerville. Requirements Engineering: Processes and Techniques (em Inglês). John
Wiley & Sons, 1998. pag. 294. ISBN 0471972088
• Ian Sommerville ; Pete Sawyer. Requirements Engineering: A good practice guide (em Inglês). 1 ed. John Wiley
& Sons, 1997. pag. 404. ISBN 0471974447
• Helen Sharp ; Yvonne Rogers ; Jenny Preece. Interaction Design: Beyond Human-computer Interaction (em
Inglês). 2 ed. John Wiley & Sons, 2002. pag. 519. ISBN 0471492787
Ligações externas
• Project Lifecycle Models [1] : How They Differ and When to Use Them.
Referências
[1] http:/ / www. business-esolutions. com/ islm. htm
Análise Estruturada
1. REDIRECIONAMENTO Análise estruturada
Projeto Estruturado
Projeto estruturado é a atividade da especificação das atividades que compõem um modelo funcional de
transformação das necessidades do usuário. São provenientes das fases de análise e diagramação e de plano de
implementação.
43
Programação estruturada é uma forma de programação de computadores que preconiza que todos os programas
possíveis podem ser reduzidos a apenas três estruturas: sequência, decisão e iteração, desenvolvida por Michael A.
Jackson no seu livro "Principles of Program Design" de 1975.
Tendo, na prática, sido transformada na Programação modular, a Programação estruturada orienta os programadores
para a criação de estruturas simples em seus programas, usando as subrotinas e as funções. Foi a forma dominante na
criação de software anterior à programação orientada por objetos.
Apesar de ter sido sucedida pela programação orientada por objetos, pode-se dizer que a programação estruturada
ainda é muito influente, uma vez que grande parte das pessoas ainda aprendem programação através dela. Além
disso, por exigir formas de pensar relativamente complexas, a programação orientada a objetos até hoje ainda não é
bem compreendida ou usada pela maioria.
Há de se acrescentar também que inúmeras linguagens ainda extremamente relevantes nos dias de hoje, como o
Cobol ainda utilizam o paradigma estruturado (muito embora possuam suporte para a orientação à objetos).
Análise Essencial
A Análise Essencial propõe o particionamento do sistema por eventos. A rigor, o valor de um sistema está na sua
capacidade de responder com eficácia a todos os estímulos a que for submetido. Assim, um sistema é construído para
responder a estímulos. A cada estímulo, o sistema deve reagir produzindo uma resposta predeterminada. A expressão
Essential Analysis, traduzida por Análise Essencial, foi proposta em 1984 por McMenamim e Palmer para refletir a
introdução dos novos conceitos que estavam sendo incorporados à Análise Estruturada clássica.
Conceito
A Análise Essencial é a técnica que orienta a análise de sistemas para a essência do negócio ao qual se destina,
independente das soluções de informática que serão utilizadas em sua construção, partindo do princípio de que os
sistemas existem independentemente dos computadores, e são feitos visando uma oportunidade de negócio.
Na Análise Essencial existem dois modelos, denominados de Modelo Essencial e Modelo de Implementação.
44
Análise Essencial
Modelo Essencial
Apresenta o sistema num nível de abstração completamente independente de restrições tecnológicas. Antes que um
sistema seja implementado, é necessário conhecer-se a sua verdadeira essência, não importando saber se sua
implementação vai ser manual ou automatizada, e nem mesmo que tipo de hardware ou software vai ser usado. O
Modelo Essencial é formado por:
• Modelo Ambiental: Define a fronteira entre o sistema e o resto do mundo
• Modelo Comportamental: Define o comportamento das partes internas do sistema necessário para interagir com o
ambiente;
Métodos Envolvidos:Modelagem de Dados e Modelagem Funcional.
Modelo Ambiental
O Modelo Ambiental é o modelo que define:
• A fronteira do sistema com o ambiente onde ele se situa, determinando o que é interno e o que é externo a ele.
• As interfaces entre o sistema e o ambiente externo, determinando que informações chegam ao sistema vindas do
mundo exterior e vice-versa.
• Os eventos do ambiente externo ao sistema aos quais este deve responder.
• Ferramentas para definição do ambiente.
O Modelo Ambiental consiste de quatro componentes:
1.
2.
3.
4.
Declaração de Objetivos
Diagrama de Contexto
Lista de Eventos
Dicionário de Dados Preliminar (opcional)
Declaração dos Objetivos
• Consiste de uma breve e concisa declaração dos objetivos do sistema.
• É dirigida para a alta gerência, gerência usuária ou outras pessoas não diretamente envolvidas no
desenvolvimento do sistema.
• Pode ter uma, duas ou várias sentenças mas não deve ultrapassar um parágrafo.
• Não deve pretender dar uma descrição detalhada do sistema.
Diagrama de Contexto
• Apresenta uma visão geral das características importantes do sistema, as pessoas, organizações ou sistemas com
os quais o sistema se comunica (Entidades Externas), os dados que o sistema recebe do mundo exterior e que de
alguma forma devem ser processados, os dados produzidos pelo sistema e enviados ao mundo exterior e a
fronteira entre o sistema e o resto do mundo.
45
Análise Essencial
46
Lista de eventos
• É uma relação de estimulos que ocorrendo no mundo exterior implicam que o sistema de algum tipo de resposta.
Tambem pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema alguma
resposta. É um ativador de uma função. É a forma como o evento age sobre o sistema. É a conseqüência do fato de
ter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz com que o
sistema então ative uma função pré-determinada para produzir a resposta esperada.
UM ESTÍMULO: É um ativador de uma função. É a forma como o evento age sobre o sistema. Éa conseqüência do
fato de ter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz com
que o sistema então ative uma função pré-determinada para produzir a resposta esperada.
UMA RESPOSTA: É o resultado gerado pelo sistema devido à ocorrência de um evento. Uma resposta é sempre o
resultado da execução de alguma função interna no sistema como conseqüência do reconhecimento pelo sistema de
que um evento ocorreu.
Modelo Comportamental
Define o comportamento interno que o sistema deve ter para se relacionar adequadamente com o ambiente.Ou, o
Modelo Comportamental é definido do ponto de vista interno, é o modelo interior do sistema. Descreve de que
maneira o sistema, enquanto um conjunto de elementos inter-relacionados, reage, internamente, como um todo
organizado, aos estímulos do exterior.
Consiste de quatro componentes:
-
DFD Particionado
Diagrama ER (DER)
Diagrama de Transição de Estado (DTE)
Dicionário de Dados Preliminar (opcional)
Especificações de processos
Análise Essencial
Modelo de Implementação
Tem como objetivo definir a forma de implementação do sistema em um ambiente técnico específico. Apresenta o
sistema num nível de abstração completamente dependente de restrições tecnológicas.
Simbologia
Conjunto de artefatos gráficos que permitem a montagem de diagramas na análise essencial
Processo: Conjunto de atividade que produzem, modificam ou atribuem qualidade às informações.
Depósito de Dados: Conjunto de informações armazenadas pelo processo para serem utilizadas por algum processo,
a qualquer momento.
Entidade Externa: É algo situado fora do escopo do sistema, que é fonte ou destino das suas informações.
Fluxo de Dados: O nome deve expressar o significado do conjunto de informações que está fluindo.
Vantagens da Análise Essencial sobre a Estruturada
• A Análise Essencial começa pelo modelo essencial, o que equivale, na Análise Estruturada, começar diretamente
pelo modelo lógico proposto.
• A Análise Estruturada aborda duas perspectivas do sistema - função e dados -, ao passo que a Análise Essencial
aborda três perspectivas - função, dados e controle.
• Na Análise Estruturada o particionamento é feito através da abordagem top-down, enquanto na Análise Essencial,
o particionamento é por eventos.
47
SADT
48
SADT
Structured Analysis and Design Technique
Structured Analysis and Design Technique — SADT é uma técnica para apresentação de idéias. Esta técnica foi
proposta por Douglas T. Ross em 1977, no artigo Ross, D. (1977) “Structured Analysis (AS): A Language for
Communicating Ideas”. IEEE Transactions on Software Engineering, vol. 3, no.1, pp. 16-34.
É uma técnica usada na construção de modelos. Segundo essa visão, cada modelo deve ter um objetivo e um ponto
de vista.
Serviço de Apoio à Diagnose e Terapia – SADT
Serviço de Apoio à Diagnose e Terapia, ou Serviço Auxiliar de Diagnóstico e Terapia (SADT) é uma modalidade de
prestação de serviços na área da saúde que se utiliza de recursos de uma fonte financiadora (SUS, Particular, ou
Convênio) com o objetivo de esclarecer o diagnóstico ou realizar procedimentos terapêuticos específicos para
pacientes externos, internos ou de emergência de um serviço de saúde. Geralmente organiza-se por um sistema
informatizado que registra a oferta dos serviços em determinadas especialidades, sejam eles próprios, terceirizados
ou contratados interna ou externamente ao estabelecimento de saúde.
DFD
O DFD ou Diagrama de Fluxos de Dados é uma ferramenta para a modelagem de sistemas. Ela fornece apenas
uma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Se estivermos desenvolvendo um
sistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menos
importância ao DFD e dedicar-nos aos Diagramas de Entidade-Relacionamento (DER).
Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos
funcionais, interligados por “dutos” e “tanques de armazenamento de dados". (Edward Yourdon)
Outros nomes para este diagrama
•
•
•
•
•
Diagrama de bolhas
DFD (abreviatura)
Modelo de processo
Diagrama de fluxo de trabalho
Modelo funcional
Componentes de um DFD
•
•
•
•
DFD Entidades Externas
DFD Processos
Fluxo de dados
Depósito de Dados
O DFD pode ter vários níveis de detalhamento de acordo com a
necessidade do sistema. O Diagrama de Contexto é uma representação
DFD
49
macro do sistema. Em seguida, temos os DFDs de níveis. O nível mais alto é conhecido como DFD de nível 0 e está
logo abaixo do diagrama de contexto. Neste nível as principais funções do sistemas são mostradas. Caso o processo
não esteja claro o suficiente o mesmo será aperfeiçoado a cada nível.
Quando se diz que o DFD fornece apenas uma visão do sistema,é pelo fato de que através de sua representação
gráfica não nos comprometemos com a sua implementação física.
O DIAGRAMA DE FLUXO DE DADOS (DFD) Todo modelo funcional de um sistema pode ser visto como sendo
formado por uma representação gráfica (uma rede de funções ou processos interligados), acompanhada da descrição
de cada função e suas interfaces. A representação gráfica do modelo funcional costuma ser expressa através de um
diagrama denominado Diagrama de Fluxo de Dados−DFD. O Conceito de Função → Caixa Preta X o------ Y = F(X)
------o Y por exemplo Elevar o X o----- No X ao -----o Y Quadrado Há ligações de entrada e de saída da caixa.
Conhecem-se os elementos de entrada da caixa. Conhecem-se os elementos de saída da caixa. Sabe-se o que a caixa
faz com as entradas para obter as saídas. Não é preciso saber como a caixa realiza suas operações, e nem a ordem.
Veja também
• Função e Processo de Negócio
• Matriz CRUD
Modelo de Entidades e Relacionamentos
1. REDIRECIONAMENTO Modelo de entidades e relacionamentos
Orientação a
objetos
Objeto
Classe
•
Instância
Abstração
Métodos
Atributo
Encapsulamento
Herança
•
Herança múltipla
Polimorfismo
Outras referências
Padrões de projeto
UML
Engenharia OO
A orientação a objetos é um paradigma de análise, projeto e programação de sistemas de software baseado na
composição e interação entre diversas unidades de software chamadas de objetos.
Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programação. De fato, o paradigma
"orientação a objeto", tem bases conceituais e origem no campo de estudo da cognição, que influenciou a área de
inteligência artificial e da linguística, no campo da abstração de conceitos do mundo real. Na qualidade de método de
modelagem, é tida como a melhor estratégia para se eliminar o "gap semântico", dificuldade recorrente no processo
de modelar o mundo real do domínio do problema em um conjunto de componentes de software que seja o mais fiel
na sua representação deste domínio. Facilitaria a comunicação do profissional modelador e do usuário da área alvo,
na medida em que a correlação da simbologia e conceitos abstratos do mundo real e da ferramenta de modelagem
(conceitos, terminologia, símbolos, grafismo e estratégias) fosse a mais óbvia, natural e exata possível.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um
sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre
estes objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no
sistema de software. Cada classe determina o comportamento (definido nos métodos) e estados possíveis (atributos)
de seus objetos, assim como o relacionamento com outros objetos.
C++, C#, Java, Object Pascal, Objective-C, Python, SuperCollider, Ruby e Smalltalk são exemplos de linguagens de
programação orientadas a objetos.
ActionScript, ColdFusion, Javascript, PHP (a partir da versão 4.0), Perl (a partir da versão 5) e VB.NET são
exemplos de linguagens de programação com suporte a orientação a objetos.
Conceitos essenciais
• Classe representa um conjunto de objetos com características afins. Uma classe define o comportamento dos
objetos através de seus métodos, e quais estados ele é capaz de manter através de seus atributos. Exemplo de
classe: Os seres humanos.
• Subclasse é uma nova classe originada de sua classe pai (ver Herança).
• Objeto / instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a
mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos da
classe Humanos: João, José, Maria.
• Atributo são características de um objeto. Basicamente a estrutura de dados que vai representar a classe.
Exemplos: Funcionário: nome, endereço, telefone, CPF,...; Carro: nome, marca, ano, cor, …; Livro: autor,
editora, ano. Por sua vez, os atributos possuem valores. Por exemplo, o atributo cor pode conter o valor azul. O
conjunto de valores dos atributos de um determinado objeto é chamado de estado.
• Método definem as habilidades dos objetos. Bidu é uma instância da classe Cachorro, portanto tem habilidade
para latir, implementada através do método deUmLatido. Um método em uma classe é apenas uma definição. A
ação só ocorre quando o método é invocado através do objeto, no caso Bidu. Dentro do programa, a utilização de
um método deve afetar apenas um objeto em particular; Todos os cachorros podem latir, mas você quer que
apenas Bidu dê o latido. Normalmente, uma classe possui diversos métodos, que no caso da classe Cachorro
poderiam ser sente, coma e morda.
• Mensagem é uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito
por sua classe. Também pode ser direcionada diretamente a uma classe (através de uma invocação a um método
estático).
• Herança (ou generalização) é o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe
(super-classe), aproveitando seus comportamentos (métodos) e variáveis possíveis (atributos). Um exemplo de
herança: Mamífero é super-classe de Humano. Ou seja, um Humano é um mamífero. Há herança múltipla quando
uma sub-classe possui mais de uma super-classe. Essa relação é normalmente chamada de relação "é um".
50
• Associação é o mecanismo pelo qual um objeto utiliza os recursos de outro. Pode tratar-se de uma associação
simples "usa um" ou de um acoplamento "parte de". Por exemplo: Um humano usa um telefone. A tecla "1" é
parte de um telefone.
• Encapsulamento consiste na separação de aspectos internos e externos de um objeto. Este mecanismo é utilizado
amplamente para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente
apenas os métodos que alteram estes estados. Exemplo: você não precisa conhecer os detalhes dos circuitos de um
telefone para utilizá-lo. A carcaça do telefone encapsula esses detalhes, provendo a você uma interface mais
amigável (os botões, o monofone e os sinais de tom).
• Abstração é a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características
menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades
existentes no domínio do sistema de software.
• Polimorfismo consiste em quatro propriedades que a linguagem pode ter (atente para o fato de que nem toda
linguagem orientada a objeto tem implementado todos os tipos de polimorfismo):
• Universal:
• Inclusão: um ponteiro para classe mãe pode apontar para uma instância de uma classe filha (exemplo em
Java: "List lista = new LinkedList();" (tipo de polimorfismo mais básico que existe).
• Paramétrico: se restringe ao uso de templates (C++, por exemplo) e generics (Java/C#).
• Ad-Hoc:
• Sobrecarga: duas funções/métodos com o mesmo nome mas assinaturas diferentes.
• Coerção: a linguagem que faz as conversões implicitamente (como por exemplo atribuir um int a um float
em C++, isto é aceito mesmo sendo tipos diferentes pois a conversão é feita implicitamente).
• Interface é um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está
comprometida a fornecer o comportamento publicado pela interface.[1]
• Pacotes são referências para organização lógica de classes e interfaces.[1]
[1] http:/ / java. sun. com/ docs/ books/ tutorial/ java/ concepts/
Referências bibliográficas
• Carlos Sica. PHP Orientado a Objetos - Fale a Linguagem da Internet. 1 ed. Rio de Janeiro: Ciência Moderna,
2006.
• Pablo Dall'Oglio. PHP Programando com Orientação a Objetos (http://www.adianti.com.br/phpoo): Inclui
Design Patterns. 1 ed. São Paulo: Novatec, 2007. pag. 576. ISBN 978-85-7522-137-2
Ver também
• Padrões de projeto de software
• Framework
• Classe
51
Ligações externas
• Página oficial da UML (http://www.uml.org/) (em inglês)
• cfoop.org OOP para ColdFusion (http://www.cfoop.org/) (em inglês)
• Conceitos de OOP em Java (http://java.sun.com/docs/books/tutorial/java/concepts/index.html) (em inglês)
(Site oficial do Java na Sun Microsystems)
• Guia do Hardware: Programação Orientada a Objetos (http://www.guiadohardware.net/artigos/
programacao-orientada-objetos/) (em português)
• Conceitos de OOP em C++ (http://www.cplusplus.com/doc/tutorial/) (em inglês)
O RUP, abreviação de Rational Unified Process (ou Processo Unificado Racional), é um processo proprietário de
Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome
IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software,
fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de
aumentar a sua produtividade no processo de desenvolvimento.
O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação
UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas
comercialmente.
É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes
projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer
escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e
responsabilidades dentro de uma organização de desenvolvimento de software.
O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por
diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".
Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os
Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.
Linhas mestras
O RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da equipe de um ciclo de
produção: parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda os
programadores a manterem-se concentrados no projeto.
Gestão de requisitos
Uma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve como documentar
a funcionalidade, restrições de sistema, restrições de projeto e requisitos de negócio.
Os casos de uso (em inglês Use Cases) e os cenários são exemplos de artefatos dependentes do processo, que têm
sido considerados muito mais eficazes na captura de requisitos funcionais.
52
Uso de arquitetura baseada em componentes
A arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo a
reutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto na
programação orientada a objetos.
O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquitetura
executável nas fases iniciais do projeto, ou seja, antes de comprometer recursos em larga escala.
Estes componentes são normalmente incluidos em infraestruturas existentes como o CORBA e o COM (Modelo de
Componentes de Objectos).
Uso de software de modelos visuais
Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue
uma maneira efetiva de se ter uma visão geral de uma solução.
O uso de modelos visuais também pode permitir que indivíduos de perfil menos técnico (como clientes) tenham um
melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.
A linguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada
pelo RUP.
Verificação da qualidade do software
Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais.
Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de
uma equipe diferente da equipe de desenvolvimento.
O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e
envolvendo todos os membros da equipe de desenvolvimento.
Gestão e Controle de Mudanças do Software
Em todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar e
monitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, o
controle de mudanças é essencial para o sucesso de um projeto.
O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro
sistema não afetarão o seu sistema.
Fases
Até agora estas linhas de guia são gerais, a serem aderidas ao percorrer do ciclo de vida de um projeto. As fases[1]
indicam a ênfase que é dada no projeto em um dado instante. Para capturar a dimensão do tempo de um projeto, o
RUP divide o projeto em quatro fases diferentes:
1.
2.
3.
4.
Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
O RUP também se baseia nos 4 Ps:
1. Pessoas
2. Projeto
3. Produto
4. Processo
53
As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definido
enquanto as fases são objetivas.
Todas as fases geram artefatos. Estes serão utilizados nas próximas fases e documentam o projeto, além de permitir
melhor acompanhamento.
Fase de concepção
A fase de concepção contém os workflows [2] necessários para que as partes interessadas (stakeholders) concordem
com os objetivos, arquitetura e o planejamento do projeto. Se as partes interessadas tiverem bons conhecimentos,
então, pouca análise será requerida. Caso contrário, uma análise maior será requerida.
Como cita o RUP, o ideal é que sejam feitas iterações. Porém estas devem ser bem definidas quanto a sua quantidade
e objetivos.
Fase de Elaboração
A fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento / documentação
dos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia a
versão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; O
plano do projeto é confiável?; Custos são admissíveis?
Fase de Construção
Na fase de construção, começa o desenvolvimento físico do software, produção de códigos, testes alfa e beta.
Deve-se aceitar testes, e processos de testes estáveis, e se os códigos do sistema constituem "baseline".
Fase de Transição
Nesta fase ocorre a entrega ("deployment") do software, é realizado o plano de implantação e entrega,
acompanhamento e qualidade do software. Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação
do cliente. Nesta fase também é realizada a capacitação dos usuários.
Disciplinas
Seis Disciplinas de Engenharia
Disciplina de Modelagem de Negócios
As organizações estão cada vez mais dependentes de sistemas de TI, tornando-se imperativo que os engenheiros de
sistemas de informação saibam como as aplicações em desenvolvimento se inserem na organização. As empresas
investem em TI, quando entendem a vantagem competitiva do valor acrescentado pela tecnologia. O objetivo de
modelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de comunicação entre
engenharia de negócios e engenharia de software. Compreender o negócio significa que os engenheiros de software
devem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais problemas na organização e
possíveis melhorias. Eles também devem garantir um entendimento comum da organização-alvo entre os clientes,
usuários finais e desenvolvedores.
Modelagem de negócios, explica como descrever uma visão da organização na qual o sistema será implantado e
como usar esta visão como uma base para descrever o processo, papéis e responsabilidades.
54
Disciplina de Requisitos
Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em um
conjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitos
detalhados para o que deve fazer o sistema.
Disciplina de Análise e Projeto("Design")
O objetivo da análise e projeto é mostrar como o sistema vai ser realizado. O objetivo é construir um sistema que:
• Execute, em um ambiente de execução específica, as tarefas e funções especificadas nas descrições de casos de
uso
• Cumpra todas as suas necessidades
• Seja fácil de manter quando ocorrerem mudanças de requisitos funcionais
Resultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de análise. O modelo de
design serve como uma abstração do código-fonte, isto é, o projeto atua como um modelo de "gabarito" de como o
código-fonte é estruturado e escrito. O modelo de projeto consiste em classes de design estruturado em pacotes e
subsistemas com interfaces bem definidas, representando o que irá se tornar componentes da aplicação. Ele também
contém descrições de como os objetos dessas classes colaboram para desempenhar casos de uso do projeto.
Disciplina de Implementação
Os efeitos da implementação são:
•
•
•
•
Para definir a organização do código, em termos de subsistemas de implementação organizadas em camadas
Para implementar classes e objetos em termos de componentes (arquivos-fonte, binários, executáveis e outros)
Para testar os componentes desenvolvidos como unidades
Integrar os resultados produzidos por implementadores individuais (ou equipes), em um sistema executável
Sistemas são realizados através da aplicação de componentes. O processo descreve como a reutilização de
componentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando o
sistema mais fácil de manter e aumentar as possibilidades de reutilização.
Disciplina de Teste
As finalidades da disciplina de teste são:
•
•
•
•
•
Para verificar a interação entre objetos
Para verificar a integração adequada de todos os componentes do software
Para verificar se todos os requisitos foram corretamente implementados
Identificar e garantir que os defeitos são abordados antes da implantação do software
Garantir que todos os defeitos são corrigidos, reanalisados e fechados
O Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Isto
permite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testes
são realizados ao longo de quatro dimensões da qualidade:confiabilidade, funcionalidade, desempenho da aplicação,
e o desempenho do sistema. Para cada uma destas dimensões da qualidade, o processo descreve como você passar
pelo teste do ciclo de planejamento, projeto, implementação, execução e avaliação.
Disciplina de Implantação
O objetivo da implantação é o de produzir com sucesso lançamentos de produtos e entregar o software para seus
usuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, a
embalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação de
ajuda e assistência aos usuários. Embora as atividades de implantação estão principalmente centradas em torno da
fase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação,
55
no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menos
detalhes do que outros workflows.
Três Disciplinas de Apoio/Suporte
Disciplina de Ambiente
O ambiente enfoca as atividades necessárias para configurar o processo para um projeto. Ele descreve as atividades
necessárias para desenvolver as diretrizes de apoio a um projeto. A proposta das atividades de ambiente é prover à
organização de desenvolvimento de software com o ambiente de desenvolvimento de software - os processos e as
ferramentas - que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é um
framework de processo, eles podem percebê-lo como um processo pesado e caro. No entanto, um conceito-chave
dentro do RUP foi que o processo RUP pode e, muitas vezes, deve ser refinado. Este foi inicialmente feito
manualmente, ou seja, por escrito, um documento de "caso de desenvolvimento" que especificou o processo refinado
para ser utilizado. Posteriormente, o produto IBM Rational Method Composer foi criado para ajudar a tornar esta
etapa mais simples, engenheiros de processos e gerentes de projeto poderiam mais facilmente personalizar o RUP
para suas necessidades de projeto. Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a versão
open-source e leve do RUP, são agora apresentados como processos distintos, por direito próprio, e atendem a
diferentes tipos e tamanhos de projetos, tendências e tecnologias de desenvolvimento de software. Historicamente,
como o RUP, muitas vezes é personalizado para cada projeto por um perito do processo RUP, o sucesso total do
projeto pode ser um pouco dependente da capacidade desta pessoa.
Disciplina de Configuração e Gerência de Mudança
A disciplina de Gestão de Mudança em negócios com RUP abrange três gerenciamentos específicos: de
configuração, de solicitações de mudança, e de status e medição.
• Gerenciamento de configuração: A gestão de configuração é responsável pela estruturação sistemática dos
produtos. Artefatos, como documentos e modelos, precisam estar sob controle de versão e essas alterações devem
ser visíveis. Ele também mantém o controle de dependências entre artefatos para que todos os artigos
relacionados sejam atualizados quando são feitas alterações
• Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de sistemas com muitos
artefatos existem diversas versões. O CRM mantém o controle das propostas de mudança
• Gerenciamento de status e medição: Os pedidos de mudança têm os estados: novo, conectado, aprovado, cedido e
completo. A solicitação de mudança também tem atributos como a causa raiz, ou a natureza (como o defeito e
valorização), prioridade, etc. Esses estados e atributos são armazenados no banco de dados para produzir
relatórios úteis sobre o andamento do projeto. A Rational também tem um produto para manter a solicitações de
mudança chamado ClearQuest. Esta atividade têm procedimentos a serem seguidos
Disciplina de Gerência de Projeto
O planejamento de projeto no RUP ocorre em dois níveis. Há uma baixa granularidade ou planos de Fase que
descreve todo o projeto, e uma série de alta granularidade ou planos de Iteração que descrevem os passos iterativos.
Esta disciplina concentra-se principalmente sobre os aspectos importantes de um processo de desenvolvimento
iterativo: Gestão de riscos; Planejamento um projeto iterativo através do ciclo de vida e para uma iteração particular;
E o processo de acompanhamento de um projeto iterativo, métricas. No entanto, esta disciplina do RUP não tenta
cobrir todos os aspectos do gerenciamento de projetos.
Por exemplo, não abrange questões como:
• Gestão de Pessoas: contratação, treinamento, etc
• Orçamento Geral: definição, alocação, etc
• Gestão de Contratos: com fornecedores, clientes, etc
56
Princípios e melhores práticas
RUP é baseado em um conjunto de princípios de desenvolvimento de software [3] e melhores práticas, por exemplo:
1.
2.
3.
4.
5.
6.
Desenvolvimento de software iterativo
Gerenciamento de requisitos
Uso de arquitetura baseada em componente
Modelagem visual de software
Verificação da qualidade do software
Controle de alteração no software
Desenvolvimento iterativo
Dado o tempo gasto para desenvolver um software grande e sofisticado, não é possível definir o problema e construir
o software em um único passo. Os requerimentos irão freqüentemente mudar no decorrer do desenvolvimento do
projeto, devido a restrições de arquitetura, necessidades do usuário ou a uma maior compreensão do problema
original. Alterações permitem ao projeto ser constantemente refinado, além de assinalarem itens de alto risco do
projeto como as tarefas de maior prioridade. De forma ideal, ao término de cada iteração haverá uma versão
executável, o que ajuda a reduzir o risco de configuração do projeto, permitindo maior retorno do usuário e ajudando
ao desenvolvedor manter-se focado.
O RUP usa desenvolvimento iterativo e incremental pelas seguintes razões:
• A integração é feita passo a passo durante o processo de desenvolvimento, limitando-se cada passo a poucos
elementos
• A integração é menos complexa, reduzindo seu custo e aumentado sua eficiência
• Partes separadas de projeto e/ou implementação podem ser facilmente identificadas para posterior reuso
• Mudanças de requisitos são registradas e podem ser acomodadas
• Os riscos são abordados no inicio do desenvolvimento e cada iteração permite a verificação de riscos já
percebidos bem como a identificação de novos
• Arquitetura de software é melhorada através de um escrutino repetitivo
Usando iterações, um projeto terá um plano geral, como também múltiplos planos de iteração. O envolvimento dos
stakeholders é freqüentemente encorajado a cada entrega. Desta maneira, as entregas servem como uma forma de se
obter o comprometimento dos envolvidos, promovendo também uma constante comparação entre os requisitos e o
desenvolvimento da organização para as pendências que surgem.
Gerenciamento de requisitos
O Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades do usuário final pela
identificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto traz como
benefícios:
• A correção dos requisitos gera a correção do produto, desta forma as necessidadades dos usuários são
encontradas.
• As características necessárias serão incluídas, reduzindo o custo de desenvolvimentos posteriores.
RUP sugere que o gerenciamento de requisitos tem que seguir as atividades:
• Análise do problema é concordar com o problema e criar medições que irão provar seu valor para a organização
• Entender as necessidades de seus stakeholders é compartilhar o problema e valores com os stakeholders-chave
e levantar quais as necessidades que estão envolvidas na elaboração da ideia
• Definir o problema é a definição das características das necessidades e esquematização dos casos de uso,
atividades que irão facilmente mostrar os requerimentos de alto-nível e esboçar o modelo de uso do sistema
57
• Gerenciar o escopo do sistema trata das modificações de escopo que serão comunicadas baseadas nos resultados
do andamento e selecionadas na ordem na qual os fluxogramas de casos de uso são atacados
• Refinar as definições do sistema trata do detalhamento dos fluxogramas de caso de uso com os stakeholders de
forma a criar uma especificação de requerimentos de software que pode servir como um contrato entre o seu
grupo e o do cliente e poderá guiar as atividades de teste e projeto
• Gerenciamento das mudanças de requisitos trata de como identificar as chegadas das mudanças de
requerimento num projeto que já começou
Uso de arquitetura baseada em componentes
Arquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão e
promove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto de objetos na
programação orientada ao objeto.
Arquitetura de software aumenta de importância quando um sistema se torna maior e mais complexo. RUP foca na
produção da arquitetura básica nas primeiras iterações. Esta arquitetura então se torna um protótipo nos ciclos
iniciais de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final do
sistema. RUP também propõe regras de projeto e restrições para capturar regras de arquitetura. Pelo
desenvolvimento iterativo é possível identificar gradualmente componentes os quais podem então ser desenvolvidos,
comprados ou reusados. Estes componentes são freqüentemente construídos em infra-estruturas existentes tais como
CORBA e COM, ou JavaEE, ou PHP
Modelagem visual de software
Abstraindo sua programação do seu código e representando-a usando blocos de construção gráfica constitui-se de
uma forma efetiva de obter uma visão geral de uma solução. Usando esta representação, recursos técnicos podem
determinar a melhor forma para implementar a dado conjunto de interdependências lógicas. Isto também constrói
uma camada intermediária entre o processo de negócio e o código necessário através da tecnologia da informação.
Um modelo neste contexto é uma visualização e ao mesmo tempo uma simplificação de um projeto complexo. RUP
especifica quais modelos são necessários e porque.
A Linguagem modelagem unificada (UML) pode ser usada para modelagem de Casos de Uso, diagrama de classes e
outros objetos. RUP também discute outras formas para construir estes modelos.
Verificar qualidade de software
Garantia da qualidade de software é o ponto mais comum de falha nos projetos de software, desde que isto é
freqüentemente algo que não se pensa previamente e é algumas vezes tratado por equipes diferentes. O RUP ajuda
no planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos os
membros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cada
membro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível de
qualidade esperado e provê testes nos processos para medir este nível.
58
Controle de alterações no software
Em todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear e
monitorar estas mudanças. RUP também define espaços de trabalho seguros (do inglês secure workspaces),
garantindo que um sistema de engenharia de software não será afetado por mudanças em outros sistemas. Este
conceito é bem aderente com arquiteturas de software baseados em componentização.
Ver também
• Rational Rose
• Enterprise Unified Process
Ligações externas
•
•
•
•
•
Treinamento de RUP [4]
Material completo [5]
Página de IBM software Rational [6]
Excelente descrição sobre o RUP (pdf) [7]
Obtendo Qualidade de Software com o RUP [8]
Referências
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
http:/ / www. synstec. com. br/ synsweb/ components/ images/ imgRup. gif
http:/ / pt. wikipedia. org/ wiki/ Fluxo_de_trabalho
http:/ / www-128. ibm. com/ developerworks/ rational/ library/ oct05/ kroll/
http:/ / www. ibm. com/ br/ shop/ trainings/
http:/ / www. wthreex. com/ rup/
http:/ / www. ibm. com/ software/ br/ rational/
ftp:/ / public. dhe. ibm. com/ / software/ pdf/ br/ RUP_DS. pdf
http:/ / www. javafree. org/ content/ view. jf?idContent=7
59
Scrum
60
Scrum
O Scrum é um processo de
desenvolvimento
iterativo
e
incremental para gerenciamento de
projetos e desenvolvimento ágil de
software. Apesar de a palavra não ser
um acrônimo, algumas empresas que
implementam o processo a soletram
com letras maiúsculas como SCRUM.
Isto pode ser devido aos primeiros
artigos de Ken Schwaber, que
capitalizava SCRUM no título.
O processo Scrum.
Apesar de Scrum ter sido destinado
para gerenciamento de projetos de software, ele pode ser utilizado em equipes de manutenção de software ou como
uma abordagem geral de gerenciamento de projetos/programas.
História
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de
automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game"
(Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e
multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente
eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John
Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na
empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka.
Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo no desenvolvimento de softwares
em todo o mundo.
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.
A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele
tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de
desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas
necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa
científica, ou até mesmo o planejamento de um casamento.
Mesmo que idealizado para ser utilizado em gestão de projetos de desenvolvimento de software ele também pode ser
usado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de
Scrums.
Scrum
Características
Scrum é um esqueleto de processo que contém grupos de práticas e papéis pré-definidos. Os principais papéis são:
1. o ScrumMaster, que mantém os processos (normalmente no lugar de um gerente de projeto)
2. o Proprietário do Produto, ou Product Owner, que representa os stakeholders e o negócio
3. a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a análise, projeto,
implementação, teste e etc.
• Cada sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
• Um backlog é conjunto de requisitos, priorizado pelo Product Owner (responsável pelo ROI e por conhecer as
necessidades do cliente);
• Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints;
• Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser
realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já
que os membros da equipe geralmente ficam em pé para não prolongar a reunião).
• Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
• Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.
O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à
habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes
são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra
função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente
as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.
Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da
equipe e entre todas as disciplinas que estão envolvidas no projeto.
Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser
resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem
empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da
habilidade da equipe de responder de forma ágil aos desafios emergentes.
Uma das grandes vantagens do Scrum, porém, é que não tem abordagem "receita de bolo" do gerenciamento de
projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir
qualidade através da aplicação de uma série de processos prescritos.
Product backlog e Sprint backlog
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O Product backlog é mantido
pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Owner pode altera-lo a a
qualquer momento, desde que os itens alterados não estejam na sprint. O Sprint backlog é uma interpretação do
Product backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns
dos itens principais no Product backlog. O Product backlog e o sprint backlog são, então, duas coisas totalmente
diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá
implementar os requisitos do produto.
Planejamento de sprint
Antes de todo sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o
próximo sprint. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que
pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto.
Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a
arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são
61
Scrum
62
então destrinchados em tarefas que se tornam o backlog do sprint.
Scrum simplificado
Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a
adaptabilidade do Scrum permite que ele seja introduzido de forma invisível ("stealth"), usando os três passos:
• Agende uma demonstração do software com seu cliente em um mês a partir de agora;
• Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não
simplesmente telas;
• Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.
Algumas características de Scrum
• Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na
saída);
• Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
• Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
• Discussões diárias de status com a equipe;
• A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
•
•
•
•
• O que fiz desde ontem?
• O que estou planejando fazer até amanhã?
• Existe algo me impedindo de atingir minha meta?
Transparência no planejamento e desenvolvimento;
Reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorizar o progresso;
Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" não necessariamente
significa "produzir mais".
Agendando discussões diárias
Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas
discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um
quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora
permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes
estão focadas no trabalho e não em questões pessoais.
Scrum Solo
Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma
grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só
programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de
sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.
Ver também
• Ken Schwaber
• John Scumniotales
• Jeff Sutherland
Scrum
Livros
• Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, January 2004, 163pp, ISBN
0-7356-1993-X
Ligações externas
Comunidade Scrum em Portugal [1]
Cursos de Scrum em Portugal [2] (Certified Scrum Master; Certified Product Owner; etc)
Scrum para Designers [3] Vários quadros kanban para ser utilizado no scrum preferencialmente para Design e UX.
Agile Software Development with Scrum [4] by Ken Schwaber
Pagina sobre Scrum da Mountain Goat [5] Uma boa definição de Scrum
Adaptive Project Management Using Scrum [6] por Craig Murphy. Este artigo provê uma overview sobre Scrum.
The New New Product Development Game [7] por Takeuchi and Nonaka. O artigo que iniciou tudo.
Scrum Delivers or Scrum and the Toyota Way [8] por Boris Gloger. Este artigo mapeia os princípios de Toyota
explicados por Liker, com as praticas de Scrum.
• Scrum and XP from the Trenches [9] por Henrik Kniberg. Um livro de 90 paginas descrevendo em detalhe como
Scrum e XP podem ser implementados a partir de uma perspectiva pratica.
•
•
•
•
•
•
•
•
• Uma série de textos de Cesar Brod sobre Scrum [10] Incluindo uma introdução, ferramentas, o uso do Scrum no
planejamento estratégico e User Stories
Referências
[1] http:/ / www. scrumpt. com
[2] http:/ / scrumpt. com/ content/ training. aspx/
[3] http:/ / www. dubaralho. com. br/ 2009/ 10/ 28/ kanban-para-design-grafico-e-user-experience-ux-usando-scrum/
[4] http:/ / bookshelved. org/ cgi-bin/ wiki. pl?AgileSoftwareDevelopmentWithScrum
[5] http:/ / www. mountaingoatsoftware. com/ scrum/
[6] http:/ / www. methodsandtools. com/ archive/ archive. php?id=18
[7] http:/ / harvardbusinessonline. hbsp. harvard. edu/ b02/ en/ common/ item_detail. jhtml?id=86116
[8] http:/ / www. glogerconsulting. de/ downloads/ Gloger_TototaScrum-170706. pdf
[9] http:/ / www. crisp. se/ henrik. kniberg/ ScrumAndXpFromTheTrenches. pdf
[10] http:/ / www. brod. com. br/ ?q=search/ node/ Scrum
63
Programação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil para
equipes pequenas e médias e que irão desenvolver software com requisitos vagos e em constante mudança. Para isso,
adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento
de software.
Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partir
desses valores, possui como princípios básicos: feedback rápido, presumir simplicidade, mudanças incrementais,
abraçar mudanças e trabalho de qualidade.
Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há um foco explícito em escopo.
Para isso, recomenda-se a priorização de funcionalidades que representem maior valor possível para o negócio.
Desta forma, caso seja necessário a diminuição de escopo, as funcionalidades menos valiosas serão adiadas ou
canceladas.
A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo na
produtividade, ao diminuir qualidade, não é compensado por perdas (ou até impedimentos) a médio e longo prazo.
Valores
•
•
•
•
•
Comunicação
Simplicidade
Feedback
Coragem
Respeito
Princípios Básicos
•
•
•
•
•
Feedback rápido
Presumir simplicidade
Mudanças incrementais
Abraçar mudanças
Trabalho de alta qualidade.
Práticas
Para aplicar os valores e princípios durante o desenvolvimento de software, XP propõe uma série de práticas. Há
uma confiança muito grande na sinergia entre elas, os pontos fracos de cada uma são superados pelos pontos fortes
de outras.
• Jogo de Planejamento (Planning Game): O desenvolvimento é feito em iterações semanais. No início da
semana, desenvolvedores e cliente reúnem-se para priorizar as funcionalidades. Essa reunião recebe o nome de
Jogo do Planejamento. Nela, o cliente identifica prioridades e os desenvolvedores as estimam. O cliente é
essencial neste processo e assim ele fica sabendo o que está acontecendo e o que vai acontecer no projeto. Como
o escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que difere
significativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, o
cliente recebe novas funcionalidades, completamente testadas e prontas para serem postas em produção.
• Pequenas Versões (Small Releases): A liberação de pequenas versões funcionais do projeto auxilia muito no
processo de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. As
versões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.
64
• Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito de
rápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlar
comunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do cliente
para o significado que ele espera dentro do projeto.
• Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso o
cliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" e
assim ter acesso a todo o sistema, você vai fazer o código exato para que esta funcionalidade seja implementada,
sem se preocupar com sistemas de autenticação e restrições de acesso. Um erro comum ao adotar essa prática é a
confusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de ser
desenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bom
andamento do XP. Código fácil deve ser identificado e substituído por código simples.
• Time Coeso (Whole Team): A equipe de desenvolvimento é formada pelo cliente e pela equipe de
desenvolvimento.
• Testes de Aceitação (Customer Tests): São testes construídos pelo cliente e conjunto de analistas e testadores,
para aceitar um determinado requisito do sistema.
• Ritmo Sustentável (Sustainable Pace): Trabalhar com qualidade, buscando ter ritmo de trabalho saudável (40
horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para a
execução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se busca
trabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre em
harmonia.
• Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindo
reuniões rápidas, apenas abordando tarefas realizadas e tarefas a realizar pela equipe.
• Posse Coletiva (Collective Ownership): O código fonte não tem dono e ninguém precisa solicitar permissão para
poder modificar o mesmo. O objetivo com isto é fazer a equipe conhecer todas as partes do sistema.
• Programação em Pares (Pair Programming): é a programação em par/dupla num único computador.
Geralmente a dupla é formada por um iniciante na linguagem e outra pessoa funcionando como um instrutor.
Como é apenas um computador, o novato é que fica à frente fazendo a codificação, e o instrutor acompanha
ajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando e
diminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando a
qualidade do código fonte gerado.
• Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para
programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela
mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros.
• Desenvolvimento Orientado a Testes (Test Driven Development): Primeiro crie os testes unitários (unit tests) e
depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o
processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do
projeto seja mantida.
• Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo de
introdução de erros e mantendo a compatibilidade com o código já existente. Refabricar melhora a clareza
(leitura) do código, divide-o em módulos mais coesos e de maior reaproveitamento, evitando a duplicação de
código-fonte;
• Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar
uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade
de erros no código fonte. Integrar de forma contínua permite saber o status real da programação.
65
Livros
•
•
•
•
•
Extreme Programming Explained: Embrace Change (2nd Edition) (ISBN 0321278658)
Planning Extreme Programming (ISBN 0201710919)
Extreme Programming Installed (ISBN 0201708426)
Agile Software Development, Principles, Patterns, and Practices (ISBN 0135974445)
Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta
qualidade [1] (ISBN 8575220470)
Ligações externas
•
•
•
•
•
•
•
Apresentando XP. Encante seus clientes com Extreme Programming [2]
Entregue seu código com confiança utilizando desenvolvimento dirigido a testes [3]
Extreme Programming: A gentle introduction [4] (em inglês)
Grupo de Usuários de Metodologias Ágeis [5] (Rio Grande do Sul)
Introdução ao Extreme Programming [6]
XPRio - eXtreme Programming [7] (Rio de Janeiro)
Curso de Programação eXtrema no IME/USP [8]
• Agilcast [9] - podcast
Referências
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
http:/ / www. improveit. com. br/ xp/ livroxp
http:/ / www. extremeprogramming. org
http:/ / xp-rs. blogspot. com
http:/ / www. improveit. com. br/ xp
http:/ / xprio. blogspot. com
http:/ / www. ime. usp. br/ ~xp
http:/ / www. agilcoop. org. br/ agilcast
66
A MSF foi criado em 1994, e originou-se da análise de times de projetos e grupo de produtos, estas análises eram
constatadas com a indústria de práticas e métodos. Estes resultados combinados eram consolidados em melhores
praticas entre pessoas e processos.
O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimento
de soluções de software dentro da Microsoft e também para os milhares de clientes e parceiros da Microsoft em todo
o mundo.
A disseminação deste método, agora na versão 4.0 no Visual Studio 2005, normalmente induz as pessoas a
compará-lo com outros “métodos” da indústria, como o RUP, CMMI ou XP, entre outros. É importante entender,
entretanto, o que são estes elementos antes de compará-los.
O MSF para Desenvolvimento Ágil de Software é um guia de procedimentos, uma coleção de boas práticas para
projetos de desenvolvimento de softwares.
Um projeto MSF é regido por ciclos ou iterações. A cada ciclo, cada componente da equipe executa suas funções e
atualiza o resultado do seu trabalho conforme a necessidade. Os ciclos se repetem até que o projeto seja concluído ou
cada versão seja lançada.
Cada componente da equipe será responsável por um ou mais papéis, dependendo do tamanho ou da complexidade
do projeto.
A Microsoft não classifica o MSF como uma metodologia, mas sim como uma disciplina. O que isso quer dizer?
Basicamente que o MSF serve como um grande guia e uma coleção de boas práticas. Porém, o MSF não se
aprofunda em detalhes.
Por exemplo, em um dado momento do projeto, o MSF diz que você terá que fazer uma especificação funcional.
Entretanto, ele não define se você deve usar UML, análise essencial ou outras técnicas. Isso fica a seu critério.
A falta de detalhes do MSF pode parecer uma deficiência a princípio, mas essa característica permitiu uma
abordagem simples e direta das técnicas apresentadas. Ou seja, o MSF permite uma fácil compreensão tanto por
parte da equipe como do cliente, além de ser bastante flexível em sua aplicação.
PRINCÍPIOS DA MSF
Foco no negócio: Entender porque o projeto existe da perspectiva do
negócio e como este valor é medido.
Comunicação: MSF aconselha a comunicação aberta em toda a equipe,
clientes e outros componentes do time.
Visão de projeto compartilhado: O processo de compartilhamento de visão
de projeto é especificado no início do projeto. Na criação desta visão
o time se comunica no intuito de identificar e resolver conflitos e
resolver visões enganosas. Isto permite definir a direção do projeto.
Esclarecer as responsabilidades compartilhadas: Todo o time compartilha
várias responsabilidades para ensinar ao time e seu relacionamento aos
respectivos stakeholders.
Mais poderes aos membros do time: Baseado em time de pares MSF dá
poderes aos membros do time por ter que atingir as metas e entregas,
aceitando o fato de terem as responsabilidades compartilhadas por tomar
decisões, direções quando necessário.
Agilidade: As iterações do ciclo de vida do modelo de processo
habilitam ajustes de cursos para a entrega do projeto em cada
67
milestone.
Investimento em qualidade: MSF tem por premissa que todo o time é
responsável por balancear os custos, e funcionalidades para preservar a
solução em qualidade e assegurar a qualidade. Membros do time precisam
construir qualidade em todas as fases até o sucesso da solução, e por
sua vez a organização deve investir em seu time em educação,
treinamento, e experiência.
Aprender com todas as experiências: Nos últimos 20 anos houve um
crescimento colossal no que diz respeito à taxa de sucesso de projetos.
Dados que a maior causa de falha são praticamente os mesmos, as
organizações de TI não aprendem com as suas falhas de projeto. O MSF
engloba o conceito de contínuo crescimento baseado em aprendizado
individual e de time.
GERENCIAMENTO DE PREPARAÇÃO
No início de um projeto da solução, antes da fase de visão/escopo, a organização precisa ter um claro entendimento
destes aspectos:
Seu cenário e requisitos de segurança específicos: para atender às
necessidades das organizações que iniciam implementações de soluções de
segurança, o Microsoft Solutions for Security (MSS) criou o SRMG. O
SRMG é um processo detalhado usado para determinar quais ameaças e
vulnerabilidades têm o maior impacto potencial em uma determinada
organização. Como cada empresa tem requisitos comerciais diferentes, é
impossível criar uma lista de vulnerabilidades que tenham o mesmo
impacto em todos os ambientes. Por isso, o SRMG permite que uma
organização aumente de forma incremental sua segurança e identifique
áreas potenciais que precisam de correção no futuro.
Suas competências internas: o objetivo desta solução é ser facilmente
entendida e imediatamente implementada por um Microsoft Certified
Systems Engineer (MCSE) com boa experiência e pelo menos uma
familiaridade básica com os materiais do Microsoft Official Curriculum
(MOC).
MODELOS MSF: TIME E PROCESSOS
Modelo de Time (Team Model) habilita a escalabilidade do projeto, identifica quem vai trabalhar durante o projeto e
linca cada time com um responsável Modelo de Processo (Process Model) provê a alta qualidade através do ciclo de
vida do projeto (Disciplina de Gerência de Riscos; Disciplina de Gerência de Projetos). O process model trabalha em
conjunto com o Team Model organizando o processo em fases distintas criação, teste, publicação.
MSF VERSÂO 4.0
A Microsoft Solution Framework versão 4.0 é uma combinação de um metamodelo, que pode ser usado como base
para processos de engenharia de software prescritivo, e dois personalizável e escalável processos de engenharia de
software. Os MSF metamodelo consiste de princípios fundamentais, uma equipa modelo e ciclos e iterações.
MSF 4.0 fornece uma ferramenta de alto nível quadro de orientações e princípios que podem ser mapeados para uma
variedade de modelos prescritivos processo. O programa está estruturado em duas metodologias descritivas e
prescritivas. A componente descritiva é chamado a MSF 4,0 metamodelo, que é uma descrição teórica do SDLC
melhores práticas para a criação de metodologias SDLC. Microsoft é da opinião de que as organizações têm
diferentes dinâmicas e contrariando as suas prioridades durante o desenvolvimento de software; algumas
organizações necessitam de uma sensível e softwares adaptáveis ambiente de desenvolvimento, enquanto outros
68
precisam de uma padronizado, repetitivo e mais ambiente controlado. Para atender estas necessidades, a Microsoft
representa o metamodelo de 4,0 MSF em dois modelos que prevêem prescritivo metodologia específica processo de
orientação, chamado Microsoft Solutions Framework para Agile Software Development (MSF4ASD) e Microsoft
Solutions Framework para Capability Maturity Model Integration Melhoria de Processos (MSF4CMMI). Note-se
que estes processos de engenharia de software podem ser modificados e personalizados de acordo com as
preferências da organização, clientes e equipe do projeto.
A filosofia MSF afirma que não existe uma única estrutura ou processo que se aplica optimamente os requisitos e
ambientes para todos os tipos de projetos. MSF, portanto, suporta múltiplas abordagens processo, para que possa ser
adaptado para apoiar qualquer projecto, independentemente da sua dimensão ou complexidade. Esta flexibilidade
significa que ele pode oferecer suporte a uma ampla variação no grau de execução dos processos de engenharia de
software, mantendo porém a um conjunto de princípios fundamentais e mentalidades.
A Microsoft Solutions Framework Process Model consiste em séries curtas de ciclos de desenvolvimento e iterações.
Este modelo abraça iterativo rápido desenvolvimento com a aprendizagem contínua e refinamento, devido ao
progressivo conhecimento da empresa e do projeto de todos os agentes envolvidos. Identificar necessidades,
desenvolvimento de produtos, e os ensaios ocorrem nas sobreposições iterações, resultando em acréscimo conclusão
de assegurar um fluxo de valor do projecto. Cada iteração tem um foco diferente eo resultado é uma porção estável
do sistema global.
Seguem-se os oito princípios fundamentais, que constituem a espinha dorsal para os outros modelos e disciplinas do
MSF:
1. comunicação aberta
2. Trabalhar em prol de uma visão compartilhada
3. Capacitar os membros da equipa
4. Estabelecer uma responsabilidade clara e partilhada
5. Concentre-se em negócio prestação valor
6. Fique ágil, esperam mudanças
7. Invista na qualidade
8. Aprenda com todas as experiências
MSF Models
MSF consiste de dois modelos:
1. MSF equipe modelo. Este artigo descreve o papel dos vários membros da equipe de projeto de desenvolvimento
de software. Os membros dessa equipe seria:
• Gerente de Produto: Principalmente lida com clientes e definir requisitos projecto, garante ainda a cliente as
expectativas são cumpridas.
• Gestão de Programas: Mantém projeto desenvolvimento e entrega ao cliente
Arquitectura: Responsável pela concepção solução, garantindo a solução óptima concepção satisfaz todas as necessidades e expectativas
•
•
•
•
Desenvolvimento: Desenvolve de acordo com as especificações.
Teste: Ensaios e garante a qualidade dos produtos
Lançamento / Operações: Garante a implantação eo bom funcionamento do software
Experiência do Usuário: Apoia questões dos usuários.
Uma pessoa pode ser atribuído a desempenhar múltiplos papéis. MSF também tem sugestão sobre como combinar a
responsabilidades, como o dono da obra não deve ser atribuída a qualquer outro papel.
2. MSF modelo de governação. Esta descreve as diferentes fases da transformação de um projeto. O Modelo de
Governança MSF tem cinco faixas sobreposição de actividade (ver abaixo), cada um com uma meta de qualidade
69
definidos. Essas faixas de atividade definir o que precisa ser cumprida e deixar como eles se realizem para a equipa
seleccionada metodologia. Por exemplo, as faixas podem ser pequenos e realizada no âmbito rapidamente para ser
coerente com uma metodologia Agile, ou pode ser serializada e alongada para ser coerente com uma metodologia
Cachoeira.
•
•
•
•
•
Envision - pense sobre o que deve ser realizado e identificar constrangimentos
Plano - planejar e projetar uma solução para atender as necessidades e expectativas dentro dessas limitações
Build - construir a solução
Estabilizar - validar a solução que vá ao encontro das necessidades e expectativas
Implantar - implantar a solução
MSF Project Management Process
•
•
•
•
•
•
•
Integrar planejamento e condução mudança de controlo
Definir e gerenciar o escopo do projeto
Preparar um orçamento e gerenciar os custos
Preparar e acompanhar os horários
Garantir que os recursos são atribuídos à direita do projecto
Gerir contratos e vendedores projeto e adquirir recursos
Facilitar a equipe e comunicações externas
• Facilitar o processo de gestão do risco
• Documento e monitorar a qualidade da equipe do processo de gestão
MSF para Agile Software Development metodologia
O MSF para Agile Software Development (MSF4ASD) se destina a ser um peso leve, processo iterativo e adaptável.
O MSF4ASD usa os princípios do desenvolvimento ágil abordagem formulada pela Agile Alliance. O MSF4ASD
prevê um processo de orientação que incide sobre as pessoas e as mudanças. Inclui aprendizagem de oportunidades e
de avaliações usando iterações em cada iteração.
MSF para Capability Maturity Model Integration metodologia Melhoria de Processos
O MSF para Capability Maturity Model Integration Melhoria de Processos (MSF4CMMI) dispõe de mais artefatos,
mais processos, mais signoffs, mais planejamento e destina-se a projectos que requerem um maior grau de
formalidade e cerimônia.
O MSF4 CMMI é uma metodologia formal para a engenharia de software. Capability Maturity Model foi criada a
partir do Software Engineering Institute da Universidade Carnegie Mellon, e é um processo de melhoria abordagem
que fornece às organizações com os elementos essenciais do processo de melhoria contínua, resultando em uma
redução SDLC, a melhoria da capacidade de cumprir as metas custo e cronograma, materiais de construção de alta
qualidade. O MSF4CMMI que ampliou o MSF4ASD orientação adicional com formalidade, comentários,
verificação e de auditoria. Isso resulta em um processo que depende do SEP e ao processo e não conformidades
confiando unicamente na confiança e na capacidade de cada um dos membros da equipe. O MSF4CMMI tem mais
documentos obrigatórios e relatórios do que a versão ágil, mais formal e desenvolvimento deste processo reduz risco
em grandes projetos de software e fornece um estatuto mensuráveis. Uma das vantagens de utilizar o CMMI é o
processo pelo qual uma avaliação padrão poderão comparar a capacidade de desenvolver software em outras
organizações.
70
O DFD de mais alto nível que representa todo o sistema como um único processo é conhecido como diagrama de
contexto, e é composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades externas. O
diagrama é uma forma de representar o objeto do estudo, o projeto, e sua relação ao ambiente.
Um diagrama de contexto permite identificar os limites dos processos, as áreas envolvidas com o processo e os
relacionamentos com outros processos e elementos externos à empresa (ex.: clientes, fornecedores)e mostra as
caracteristicas do sistema como:
- Organizações/sistemas/pessoas que se comunicam com o sistema;
- Dados que o sistema absorve e deve processar;
- Dados que o sistema gera para o ambiente;
- Fronteira do sistema com o ambiente.
O DFD ou Diagrama de Fluxos de Dados é uma ferramenta para a modelagem de sistemas. Ela fornece apenas
uma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Se estivermos desenvolvendo um
sistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menos
importância ao DFD e dedicar-nos aos Diagramas de Entidade-Relacionamento (DER).
Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos
funcionais, interligados por “dutos” e “tanques de armazenamento de dados". (Edward Yourdon)
Outros nomes para este diagrama
•
•
•
•
•
Diagrama de bolhas
DFD (abreviatura)
Modelo de processo
Diagrama de fluxo de trabalho
Modelo funcional
Componentes de um DFD
•
•
•
•
DFD Entidades Externas
DFD Processos
Fluxo de dados
Depósito de Dados
O DFD pode ter vários níveis de detalhamento de acordo com a
necessidade do sistema. O Diagrama de Contexto é uma representação
macro do sistema. Em seguida, temos os DFDs de níveis. O nível mais
alto é conhecido como DFD de nível 0 e está logo abaixo do diagrama de contexto. Neste nível as principais funções
do sistemas são mostradas. Caso o processo não esteja claro o suficiente o mesmo será aperfeiçoado a cada nível.
Quando se diz que o DFD fornece apenas uma visão do sistema,é pelo fato de que através de sua representação
gráfica não nos comprometemos com a sua implementação física.
O DIAGRAMA DE FLUXO DE DADOS (DFD) Todo modelo funcional de um sistema pode ser visto como sendo
formado por uma representação gráfica (uma rede de funções ou processos interligados), acompanhada da descrição
71
de cada função e suas interfaces. A representação gráfica do modelo funcional costuma ser expressa através de um
diagrama denominado Diagrama de Fluxo de Dados−DFD. O Conceito de Função → Caixa Preta X o------ Y = F(X)
------o Y por exemplo Elevar o X o----- No X ao -----o Y Quadrado Há ligações de entrada e de saída da caixa.
Conhecem-se os elementos de entrada da caixa. Conhecem-se os elementos de saída da caixa. Sabe-se o que a caixa
faz com as entradas para obter as saídas. Não é preciso saber como a caixa realiza suas operações, e nem a ordem.
Veja também
• Função e Processo de Negócio
• Matriz CRUD
Diagrama entidade relacionamento
Diagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistema
com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. É usado
para representar o modelo conceitual do negócio. Não confundir com modelo relacional, que representam as tabelas,
atributos e relações materializadas no banco de dados.
• MER: Conjunto de conceitos e elementos de modelagem que o projetista de banco de dados precisa conhecer. O
Modelo é de Alto Nível.
• DER: Resultado do processo de modelagem executado pelo projetista de dados que conhece o MER.
Tipos de relações
Os tipos de relações que são utilizadas neste diagrama:
• Relação 1..1 (lê-se relação um para um) - indica que as tabelas têm relação unívoca entre si. Você escolhe qual
tabela vai receber a chave estrangeira;
• Relação 1..n (lê-se um para muitos) - a chave primária da tabela que tem o lado 1 vai para a tabela do lado N.
No lado N ela é chamada de chave estrangeira;
• Relação n..n (lê-se muitos para muitos) - quando tabelas têm entre si relação n..n, é necessário criar uma nova
tabela com as chaves primárias das tabelas envolvidas, ficando assim uma chave composta, ou seja, formada por
diversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n, sendo que o lado n
ficará com a nova tabela criada.
Ver também
•
•
•
•
•
•
•
•
MER - Modelo de Entidades e Relacionamentos
Modelo Relacional
Administração de dados
UML
IDEF1X
Ferramenta CASE
DBDesigner
Matriz CRUD
72
73
Um dicionário de dados (do inglês data dictionary) é uma coleção de metadados que contêm definições e
representações de elementos de dados.
Dentro do contexto de SGBD, um dicionário de dados é um grupo de tabelas, habilitadas apenas para leitura ou
consulta, ou seja, é uma base de dados, propriamente dita, que entre outras coisas, mantém as seguintes informações:
•
•
•
•
•
Definição precisa sobre elementos de dados
Perfis de usuários, papéis e privilégios
Descrição de objetos
Integridade de restrições
Stored procedures (pequeno trecho de programa de computador, armazenado em um SGBD, que pode ser
chamado freqüentemente por um programa principal) e gatilhos
• Estrutura geral da base de dados
• Informação de verificação
• Alocações de espaço
Um dos benefícios de um dicionário de dados bem preparado é a consistência entre itens de dados através de
diferentes tabelas. Por exemplo, diversas tabelas podem conter números de telefones; utilizando uma definição de
um dicionário de dados bem feito, o formato do campo 'número de telefone' definido com "( )9999-9999" deverá ser
obedecido em todas as tabelas que utilizarem esta informação.
Quando uma organização constrói um dicionário de dados de dimensão empresarial, o intuito deve ser o de
padronizar precisamente definições semânticas a serem adotadas na empresa toda; portanto, ele deve incluir tanto
definições semânticas como de representação para elementos de dados, sendo que os componentes semânticos focam
na criação precisa do significado dos elementos de dados, e de outro lado, as definições de representação indicam
como os elementos de dados são armazenados em uma estrutura de computador de acordo com seu tipo, ou seja, se
são dados do tipo inteiro, caracter ou formato de data (veja Tipos de Dados). Os dicionários de dados são mais
precisos que glossários (termos e definições) porque costumam ter uma ou mais representações de como o dado é
estruturado e podem envolver ontologias completas quando lógicas distintas sejam aplicadas a definições desses
elementos de dados.
Os dicionários de dados são gerados, normalmente, separados do Modelo de Dados visto que estes últimos
costumam incluir complexos relacionamentos entre elementos de dados.
Notação
</pre>
Símbolo
Significado
=
é composto de
()
opcional (pode estar presente ou ausente)
{}
iteração
[]
escolha em uma das alternativas
**
comentário
@
identificador (chave) em um depósito
|
separa opções alternativas na construção [].
Tabela de decisão
Tabela de decisão
A Tabela de decisão é uma maneira de expressar, em forma de tabela, qual o conjunto de condições que é
necessário ocorrer para que um determinado conjunto de ações deva ser executado. O ponto principal de uma tabela
de decisão é a regra de decisão, que define o conjunto de ações a ser tomado, a partir de um conjunto de condições.
Uma tabela de decisão é composta de:
• uma área de condições, onde são relacionadas as condições que devem ser verificadas para que seja executado um
conjunto de ações;
• uma área de ações, que exibe o conjunto de ações que deve ser executado caso um determinado conjunto de
condições ocorra;
• regras de decisão, representadas pelas colunas, que apresentam a combinação das condições com as ações a serem
executadas.
Na tabela acima, definimos que para ser considerado exame especial, o avaliado teria que ter mais de 40 anos ou
cargo de chefia com mais de 2 anos no cargo.
Para que seja definida a quantidade de regras da tabela, basta que multipliquemos a quantidade de respostas
possíveis de cada condição.
Ex.
Condição 1 sim/não: =2
Condição 2 sim/não: =2
Condição 3 Sim/não: =2 x
Quantidade de Regras: =8
74
Árvore de decisão
75
Árvore de decisão
Uma árvore de decisão é uma representação de uma tabela de decisão sob a forma de uma árvore. Tem a mesma
utilidade da tabela de decisão. Trata-se de uma maneira alternativa de expressar as mesmas regras que são obtidas
quando se constrói a tabela.
Seja a especificação do processo de cálculo do valor da conta de energia elétrica. Uma árvore de decisão para
expressar tal problema seria:
Diagramas da UML 2.0 editar
[1]
Diagramas Estruturais
•
•
•
•
•
•
Diagrama de classes
Diagrama de objetos
Diagrama de componentes
Diagrama de instalação
Diagrama de pacotes
Diagrama de estrutura
Diagramas Comportamentais
•
•
•
Diagrama de Caso de Uso
Diagrama de atividade
Diagramas de Interação
•
•
•
•
Diagrama de sequência
Diagrama de Interatividade
Diagrama de colaboração ou comunicação
Diagrama de tempo
Em engenharia de software e eletrônica digital, um diagrama de transição de estados é uma representação do
estado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Com
isso, o objeto pode passar de um estado inicial para um estado final) através de uma transição.
76
Conceitos
• Estado: Condição ou situação durante a vida de um objeto na qual ele satisfaz algumas condições, executa
algumas atividades ou espera por eventos.
• Transição: O relacionamento entre dois estados, indicando que o objeto que está no primeiro estado irá passar
para o segundo estado mediante a ocorrência de um determinado evento e em certos casos uma condição.
• Condição: causa necessária para que haja a transição de estado. Decorre da ocorrência de um evento ou
circunstância que propicia a transição de estado.
• Estado inicial: Estado por onde se começa a leitura de um diagrama de estado.
• Estado final: Estado que representa o fim de uma máquina.
• Barra de Sincronização: Semelhante a um Fork do Diagrama de atividade.
• Estado composto: Estado composto por outras máquinas de estado organizadas em regiões que são executadas
em paralelo.
• Sincronização: permite que os relógios de dois ou mais processos paralelos estejam sincronizados em um
determinado momento do processo.
• Ação: atividade do sistema que efetua a transição de estado.
Exemplo
Um exemplo simples seria um semáforo (sinal de trânsito).
Cada estado corresponde a uma situação que ocorrerá. Quando verde, os carros podem prosseguir na via. Passado um
tempo, é acionada a tarefa de mudar para amarelo. Então o semáforo passa de verde para amarelo. Aqui os carros
ficam em estado de atenção e já aguardam a próxima transição.
O próximo passo é passar para vermelho. Nesse estado, os carros estão parados na via. De vermelho, o próximo
estado somente será verde, assim, os carros podem voltar a trafegar na via.
Diagrama de transição de estados de um semáforo
Diagrama de transição de estados das estações
do ano
Ver também
Referências
[1] http:/ / pt. wikipedia. org/ w/ index. php?title=Predefinição:Diagramas& action=edit
Um processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a
finalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendo
considerado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratos
de desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.
Passos/Atividades Processo
Análise Econômica
Visa a estabelecer se o projeto de Software gerará lucro, e se a receita gerada será o suficiente para cobrir os custos.
Este processo acompanha todas as demais etapas de desenvolvimento do Software.
A extração dos requisitos de um desejado produto de software é a primeira tarefa na sua criação. Embora o cliente,
provavelmente, acredite saber o que o software deva fazer, esta tarefa requer habilidade e experiência em engenharia
de software para reconhecer a incompletude, ambigüidade ou contradição nos requisitos.
Especificação
A especificação é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma forma
matematicamente rigorosa. Na prática, somente especificações mais bem sucedidas foram escritas para aplicações
bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas de software de missão crítica
sejam freqüentemente bem especificados antes do desenvolvimento da aplicação. Especificações são mais
importantes para interfaces externas que devem permanecer estáveis.
Arquitetura de Software
A arquitetura de um sistema de software remete a uma representação abstrata daquele sistema. Arquitetura é
concernente à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também
assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura também direciona as interfaces entre os
sistemas de software e outros produtos de software, como também com o hardware básico ou com o sistema
operacional.
Implementação (ou codificação)
A transformação de um projeto para um código deve ser a parte mais evidente do trabalho da engenharia de software,
mas não necessariamente a sua maior porção..
77
Teste
Teste de partes do software, especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhando
juntos, é um papel da engenharia de software.
Documentação
Uma importante tarefa é a documentação do projeto interno do software para propósitos de futuras manutenções e
aprimoramentos. As documentações mais importantes são das interfaces externas.
Suporte e Treinamento de Software
Uma grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor não perceber que não
importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém da
organização irá usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco
familiares. Então, como parte da fase de desenvolvimento, é muito importante o treinamento para os usuários de
software mais entusiasmados, alternando o treinamento entre usuários neutros e usuários favoráveis ao software.
Usuários irão ter muitas questões e problemas de software os quais conduzirão para a próxima fase.
Manutenção
A manutenção e melhoria de software lidam com a descoberta de novos problemas e requisitos. Ela pode tomar mais
tempo que o gasto no desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar códigos que
combinem com o projeto original, mas determinar como o software trabalhará em algum ponto depois da
manutenção estar completa, pode requerer um significativo esforço por parte de um engenheiro de software. Cerca
de ⅔ de todos os engenheiros de software trabalham com a manutenção, mas estas estatísticas podem estar
enganadas. Uma pequena parte destes trabalha na correção de erros. A maioria das manutenções é para ampliar os
sistemas para novas funcionalidades, as quais, de diversas formas, podem ser consideradas um novo trabalho.
Analogamente, cerca de ⅔ de todos os engenheiros civis, arquitetos e construtores trabalham com manutenção de
uma forma similar.
Padrões
O processo de desenvolvimento de software tem sido objetivo de vários padrões, que visam a certificação de
empresas como possuidoras de um processo de desenvolvimento, o que garantiria certo grau de confiança aos seus
contratantes.
Alguns padrões existentes atualmente:
•
•
•
•
CMMI (anteriormente CMM)
SPICE
ISO 12207
MPS/Br
Modelos de Processo
Há uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a
produtividade e qualidade. Alguns tentaram sintetizar e formalizar a tarefa aparentemente incontrolável de escrever
um software. Outros aplicaram técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento de
projeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. Como um grande número de
projetos de software não atendem suas expectativas em termos de funcionalidades, custo, ou cronograma de entrega,
ainda não existe um modelo de processo perfeito para todas aplicações.
78
Processo em cascata
O mais antigo e bem conhecido processo é o Modelo em cascata, onde os desenvolvedores (a grosso modo) seguem
estes passos em ordem. Eles estabelecem os requisitos, os analisam, projetam uma abordagem para solução,
arquitetam um esboço do software, implementam o código, testam (inicialmente os testes unitários e então os testes
de sistema), implantam e mantêm. Depois que cada passo é terminado, o processo segue para o próximo passo, tal
como construtores que não revisam as fundações de uma casa depois que as paredes foram erguidas. Se as iterações
não são incluídas no planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo,
nos requisitos), então o processo inteiro da engenharia de software deve ser executado até o fim, resultando em
funcionalidades de software desnecessárias ou sem uso.Para isso tem que se fazer o implemento dos requisitos
anteriormente analisados pelo programador.
Processos Iterativos
O Desenvolvimento iterativo e incremental prescreve a construção de uma porção pequena, mas abrangente, do
projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que
possam a levar ao desastre. O processo iterativo é preferido por desenvolvedores porque lhes fornece um potencial
para atingir os objetivos de projeto de um cliente que não sabe exatamente o que quer, ou quando não se conhece
bem todos os aspectos da solução.
Processos de desenvolvimento ágil de software são construídos com os fundamentos do desenvolvimento iterativo.
Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismos de controle primário. O
feedback é produzido por testes regulares e das versões do software desenvolvido.
Processos ágeis
Os processos em Desenvolvimento ágil de software parecem ser mais eficientes do que as metodologias antigas.
Utiliza menos tempo do programador no desenvolvimento de softwares funcionais de alta qualidade, mas tem a
desvantagem de ter uma perspectiva de negocio que não provê uma capacidade de planejamento em longo prazo. Em
essência, eles provem mais funcionalidades por custo/benefício, mas não dizem exatamente o que a funcionalidade
irá fazer.
Existem várias metodologias que podem ser consideradas como abordagens ágeis, entre elas: Scrum, Programação
extrema, FDD, Crystal Clear, DSDM entre outras.
A Programação Extrema (XP), é o mais bem conhecido processo ágil. Em XP, as fases são continuadas em passos
extremamente pequenos (ou contínuos) comparados aos processos antigos. A primeira passada (iteração incompleta)
através das etapas deve levar um dia ou uma semana, ao invés de meses ou anos para cada fase completa do modelo
em cascata. Primeiramente, escreve-se um autômato de teste, que provê objetivos concretos para o desenvolvimento.
Depois é codificado (por um par de programadores), este passo está completo quando todos os testes se concluem, e
os programadores não pensem em nada mais que possa ser testado. Projetistas e Arquitetos executam uma
refatoração do código. O projeto é feito por pessoas que estão codificando. O sistema incompleto mas funcional é
entregue e demonstrado para os usuários. Neste ponto, os envolvidos iniciam novamente uma nova fase de escrita e
teste para as próximas partes mais importantes do sistema.
Método formal
Os Métodos Formais são abordagens matemáticas para resolver problemas de software e hardware ao nível de
requisito, especificação e projetos. Exemplos de métodos formais incluem Método-B, Redes Petri, RAISE e VDM.
Várias notações de especificação formal estão disponíveis, tais como a notação-Z. De forma mais genérica, a teoria
do autômato pode ser usada para construir e validar o comportamento da aplicação para o projeto de um sistema de
máquina de estado finito.
79
Máquinas de estado finito baseadas nestas metodologias permitiram especificar software executáveis e contornar a
codificação convencional.
Ver também
Alguns métodos de desenvolvimento de software
•
•
•
•
•
•
•
•
•
•
•
Modelo em cascata
Modelo em espiral
Modelo desenvolvimento dirigido
Modelo baseado experiência usuario
Modelo Bottom Up
Modelo Balbúrdia
Prototipacão
Modelo Top Down
Modelo V
Scrum
Temas relacionados
•
•
•
•
•
•
•
•
•
•
•
•
•
Modelo abstrato
Modelo IPO+S
Processo
Modelagem de Dados
Matriz CRUD
Paradigmas de programação
Projeto
Ciclo de vida de desenvolvimento de sistema
Documentação de Software
Projeto de Sistemas
Esforço de teste
RUP
Praxis (engenharia de software)
Softwares de apoio
• dotProject
• Trac
• Subversion
80
A Análise de requisitos de software é a primeira fase de desenvolvimento de software. É nesta fase que o analista
faz as primeiras reuniões com os clientes e/ou usuários do software para conhecer as funcionalidades do sistema que
será desenvolvido. É nesta fase também que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ou
usuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o software terá. As
entrevistas estruturadas são um método utilizado para esta fase e que poderão ter um papel importante na ajuda à
compreensão de todas as funcionalidades pretendidas pelo cliente.
Especificação de Programa
Uma especificação de programa é a definição do que se espera que um programa de computador faça. Ela pode ser
informal, neste caso ela pode ser considerada como um blueprint ou manual de usuário do ponto de vista do
desenvolvedor, ou formal, no caso de ela ser definida principalmente em termos matemáticos ou programáticos.
Na prática, as especificações mais bem sucedidas são escritas para a compreensão e ajustes em uma aplicação que já
se encontra bem desenvolvida, embora sistemas de sistemas de segurança críticos sejam cuidadosamente
especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas
que devem permanecer estáveis.
Ver também
•
•
•
•
•
•
•
•
•
•
•
Métodos formais
Especificação formal
Transformação programa
Contrato por projeto
Notação de maquina abstrata
Método desenvolvimento Vienna
Notação Z
Linguagem de especificação
Refinamento
81
A arquitetura de software de um sistema consiste dos componentes de software, suas propriedades externas, e seus
relacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software do
sistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra as
decisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entre
projetos.
Introdução
O campo da ciência da computação tem lidado com problemas associados, como a complexidade da informação,
desde sua criação.[1] Os primeiros problemas de complexidade foram resolvidos pelos desenvolvedores através da
escolha da estrutura de dados, do desenvolvimento de algoritmos e pela aplicação de conceitos de separação de
escopos. Embora o termo arquitetura de software seja relativamente novo na industria, os princípios fundamentais
deste campo vem sendo aplicados esporadicamente pela engenharia de software desde o inicio dos anos 80. As
primeiras tentativas de capturar e explicar a arquitetura de software do sistema foram imprecisas e desorganizadas –
freqüentemente caracterizadas por um conjunto de diagramas.[2] Durante o decorrer da década de 90 houve um
esforço concentrado para definir e codificar os aspectos fundamentais desta disciplina. Inicialmente um conjunto de
padrões de projeto, estilo, melhores práticas, descrição de linguagens, e lógica formal foram desenvolvidas durante
este período.
A disciplina de arquitetura de software é centrada na idéia da redução da complexidade através da abstração e
separação de interesses. O glossário do site oficial SOFTWARE ENGENEERING INSTITUTE (Instituto de
Engenharia de Software) [3] descreve que arquitetura de software é a estrutura ou estruturas de um sistema, com
todos os elementos de software vendo e tendo suas propriedades vistas por todos os outros elementos e
relacionamentos.
Sendo a arquitetura de sistema uma disciplina em maturação, sem regras claras, a ação do arquiteto é ainda uma
composição de arte e ciência. Os aspectos de arte da arquitetura de software são devido ao fato que os sistemas de
software comerciais suportam alguns aspectos de um negócio ou missão. Como o direcionamento de negócio chave
para o suporte sistemas são descrito nos cenários como requisitos não-funcionais de sistema, também conhecidos
como atributos de qualidade, que determinam como um sistema ira se comportar.[4] Cada sistema é único devido a
natureza do negócio que ele suporta, tal que o nível dos atributos de qualidade exigidos de um sistema como
compatibilidade, extensibilidade, confiabilidade, manutenabilidade, disponibilidade, segurança, usabilidade, dentre
outros – irão variar com cada aplicação.[4]
Para trazer a perspectiva do usuário para dentro da arquitetura de software, pode-se dizer que a arquitetura de
software dá a direção dos passos que serão tomados e as tarefas envolvidas em cada área de especialidade e interesse
do usuário, por exemplo, stakeholders de sistemas de software, os desenvolvedores de software, o grupo de suporte
ao software do sistema operacional, aos testadores e usuários de negocio final. Neste sentido, a arquitetura de
software se torna a ligação das múltiplas perspectivas que um sistema traz nele embutido. O fato de que estas várias
perspectivas diferentes possam ser postas juntas em uma arquitetura de software padrão justifica e valida a
necessidade de criação da arquitetura de software antes do desenvolvimento do software para que projeto alcance a
maturidade.
82
História
A origem da arquitetura de software como um conceito foi primeiramente identificado no trabalho de pesquisa de
Edsger Dijkstra em 1968 e David Parnas no início de 1970. Estes cientistas enfatizaram a importância das estruturas
de um sistema de software e a criticidade da identificação da sua estrutura.[5] O estudo deste campo aumentou de
popularidade desde o inicio de 1990 com os trabalhos de pesquisa concentrando-se nos padrões de estilo de
arquitetura, linguagens de descrição de arquitetura, documentação de arquitetura, e métodos formais.[6] Muitas
instituições de pesquisa tais como a Carnegie Mellon University e a University of California, Irvine estavam
realizando muitas pesquisas no campo da arquitetura de software. Mary Shaw e David Garlan da Carnegie Mellon
escreveram um livro intitulado Software Architecture: Perspectives on an Emerging Discipline em 1996, o qual
trazia a tona conceitos da arquitetura de software, tais como componentes, conexões, estilos, etc. Os esforços do
UCI's (Institute for Software Research) na pesquisa da arquitetura de software foram inicialmente direcionado para
os estilos de arquitetura, descrições de linguagens arquitetura, e arquiteturas dinâmicas.
ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems[7] foi a
primeira norma padrão na área de arquitetura de software, e foi recentemente adotada pelo ISO como ISO/IEC DIS
25961.
Descrevendo arquiteturas
Linguagem de descrição de arquitetura
As Linguagens de descrição de arquitetura (LDAs) são usadas para descrever a arquitetura de software. Vários
diferentes LDAs foram desenvolvidas por diferentes organizações, incluindo Wright (desenvolvido por Carnegie
Mellon), Acme (desenvolvido por Carnegie Mellon), xADL (desenvolvido por UCI), Darwin (desenvolvido por
Imperial College London), DAOP-ADL (desenvolvido pela University of Málaga). Elementos comuns de uma LDA
são componente, conexão e configuração.
Visões
A arquitetura de software é normalmente organizada em visões[8] , as quais são análogas aos diferentes tipos de
'blueprint[9]' utilizados no estabelecimento da arquitetura. Na Ontologia estabelecida pela ANSI/IEEE 1471-2000,
visões são instancias de pontos de vista, onde um ponto de vista existe para descrever a arquitetura na perspectiva de
um conjunto de stakeholders e seus consortes.
Algumas possíveis visões são:
•
•
•
•
•
•
Visão funcional/lógica
Visão de código.
Visão de desenvolvimento/estrutural
Visão de concorrência/processo/thread
Visão física/evolutiva
Visão de ação do usuário/feedback
Várias linguagens para descrição da arquitetura de software foram inventadas, mas nenhum consenso foi ainda
alcançado em relação a qual conjunto de símbolos ou sistema representação deve ser adotado. Alguns acreditam que
a UML ira estabelecer um padrão para representação de arquitetura de software. Outros acreditam que os
desenvolvimentos efetivos de software devem contar com a compreensão única das restrições de cada problema, e
notações tão universais são condenadas a um final infeliz porque cada uma prove um notação diferenciada que
necessariamente torna a notação inútil ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferação de
linguagens de programação e a sucessão de tentativas falhas para impor uma simples 'linguagem universal' na
programação, como uma prova da tendência do software para a diversidade e não para padrões.
83
Padrões de arquitetura
•
•
•
•
•
DODAF [10]
MODAF [11]
TOGAF [12]
Zachman framework [13]
Federal Enterprise Architecture [14]
Exemplos de arquitetura
Há muitas formas comuns de projetar módulos de software de computador e suas comunicações, entre elas:
•
•
•
•
•
•
•
Cliente-Servidor
Computação distribuída
P2P
Quadro Negro
Criação implícita
Pipes e filtros
Plugin
•
•
•
•
•
Aplicação monolítica
Modelo em três camadas
Analise de sistema estruturada (baseada em módulos, mas usualmente monolíticas em dentro dos módulos)
Arquitetura orientada a serviço
Arquitetura orientada a busca
[1] University of Waterloo (2006). A Very Brief History of Computer Science (http:/ / www. cs. uwaterloo. ca/ ~shallit/ Courses/ 134/ history.
html). Página visitada em 2006-09-23.
[2] IEEE Transactions on Software Engineering (2006). Introduction to the Special Issue on Software Architecture (http:/ / csdl2. computer. org/
persagen/ DLAbsToc. jsp?resourcePath=/ dl/ trans/ ts/ & toc=comp/ trans/ ts/ 1995/ 04/ e4toc. xml& DOI=10. 1109/ TSE. 1995. 10003).
Página visitada em 2006-09-23.
[3] SEI (2010). Glossary? (http:/ / www. sei. cmu. edu/ architecture/ start/ glossary). Página visitada em 2010-01-31.
[4] SoftwareArchitectures.com (2006). Intro to Software Quality Attributes (http:/ / www. softwarearchitectures. com/ one/ Designing+
Architecture/ 78. aspx). Página visitada em 2006-09-23.
[5] SEI (2006). Origins of Software Architecture Study (http:/ / www. sei. cmu. edu/ architecture/ roots. html). Página visitada em 2006-09-25.
[6] Garlan & Shaw (2006). An Introduction to Software Architecture (http:/ / www. cs. cmu. edu/ afs/ cs/ project/ able/ ftp/ intro_softarch/
intro_softarch. pdf). Página visitada em 2006-09-25.
[7] http:/ / en. wikipedia. org/ wiki/ IEEE_1471
[8] Clements, Paul. Documenting Software Architectures: Views and Beyond. 2 ed. Boston: Addison-Wesley, 2003. pag. pp. 13-15. ISBN
0201703726
[9] http:/ / en. wikipedia. org/ wiki/ Blueprint
[10] http:/ / en. wikipedia. org/ wiki/ Department_of_Defense_Architecture_Framework
[11] http:/ / en. wikipedia. org/ wiki/ MODAF
[12] http:/ / en. wikipedia. org/ wiki/ TOGAF
[13] http:/ / en. wikipedia. org/ wiki/ Zachman_framework
[14] http:/ / en. wikipedia. org/ wiki/ Federal_Enterprise_Architecture
84
Ver também
•
•
•
•
•
•
•
•
Padrões de projeto de software
Antipadrões de software
Modelagens de dados padrões
Matriz de estrutura de dependência
Arquitetura de negócio
Arquitetura de informações
Arquitetura de processo
Arquiteto de software
Ligações externas
• Software architecture definitions at Carnegie Mellon University Software Engineering Institute (http://www.sei.
cmu.edu/architecture/definitions.html)
• Software architecture vs. software design (http://eden-study.org/articles/2003/icse03.pdf)
• Worldwide Institute of Software Architects (http://www.wwisa.org/)
• Grady Booch's [[Handbook of Software Architecture (http://www.booch.com/architecture/index.jsp)] project]
• SoftwareArchitectures.com [[Independent resource of information on the discipline (http://www.
SoftwareArchitectures.com)]]
• International Association of Software Architects (http://www.iasahome.org/)
• Microsoft Architecture Journal (http://www.architecturejournal.net/)
• Pangea - Professional and Academic Network to the Growing and Evolution of Architecture (Portuguese) (http://
pangeanet.org/)
85
86
Programação é o processo de escrita, teste e
manutenção de um programa de computador. O
programa é escrito em uma linguagem de
programação, embora seja possível, com alguma
dificuldade, escrevê-lo directamente em linguagem
de máquina. Diferentes partes de um programa
podem ser escritas em diferentes linguagens.
Diferentes linguagens de programação funcionam de
diferentes modos. Por esse motivo, os
programadores podem criar programas muito
diferentes para diferentes linguagens; muito embora,
teoricamente, a maioria das linguagens possa ser
usada para criar qualquer programa. Para mais
informações sobre estes métodos, veja Linguagem
de programação.
Software é um nome colectivo para programas de
computadores e dados.
Há várias décadas se debate se a programação é mais
semelhante a uma arte (Donald Knuth), a uma
ciência, à matemática (Edsger Dijkstra), à
engenharia (David Parnas), ou se é um campo
completamente novo.
Programas ou algoritmos?
Pequeno programa em linguagem de programação C que imprime na
tela se o número passado a ele como argumento é primo ou não. O
código fonte está sendo visualizado em um IDE com suporte a coloração
de sintaxe e indentação de código.
Um algoritmo é uma sequência de passos para
realizar uma tarefa ou resolver um problema. Em nosso dia a dia utilizamos algoritmos para realizar nossas
atividades, definindo a sequência de atividades que devemos fazer para atingir um objetivo.
Um algoritmo é, num certo sentido, um programa abstrato — dizendo de outra forma, um programa é um algoritmo
concretizado. No entanto, os programas são, à excepção dos menores, visualizados mais facilmente como uma
colecção de algoritmos menores combinados de um modo único — da mesma forma que uma casa é construída a
partir de componentes.
Dessa forma, um algoritmo é uma descrição de como um computador pode ser levado a executar uma operação
simples e específica, como, por exemplo, uma ordenação. Um programa, por outro lado, é uma entidade que na
verdade implementa uma ou mais operações de forma que seja útil para as pessoas.
A criação de um programa de computador consiste de cinco passos principais:
1.
2.
3.
4.
Reconhecer a necessidade de um programa para resolver um problema.
Planificar o programa e seleccionar as ferramentas necessárias para resolver o problema.
Escrever o programa na linguagem de programação escolhida.
Compilação: tradução do código fonte legível pelo homem em código executável pela máquina, o que é feito
através de compiladores e outras ferramentas.
5. Testar o programa para ter a certeza de que funciona; se não, regressar ao passo 3.
Estes cinco passos são colectivamente conhecidos como engenharia de software. A programação põe ênfase nos
passos 2, 3 e 4. A codificação põe ênfase no passo 3. O termo coder, por vezes usado como sinônimo para
programador, pode tornar-se aviltante porque ignora as capacidades necessárias para lidar com os outros quatro
passos.
História
Heron de Alexandria no século primeiro inventou
teatros automatizados que usavam programação
análoga para controlar os fantoches, portas, luzes e
efeitos de som.
A mais antiga programadora de computadores que se
conhece é Ada Lovelace, filha de Anabella e de Lord
Byron (o poeta). Anabella transmitiu a Ada o seu amor
à matemática, a qual, depois de conhecer Charles
Babbage, traduziu e expandiu uma descrição da sua
máquina analítica. Muito embora Babbage nunca tenha
completado a construção de nenhuma das suas
máquinas, o trabalho que ele e Ada desenvolveram
sobre elas, garantiu a Ada o título de primeira
Um bug, que foi depurado em 1947.
programadora de computadores do mundo (veja as
notas de Ada Byron sobre a máquina analítica. A linguagem de programação Ada recebeu o seu nome.
Um dos primeiros programadores que se tem notícia de ter completado todos os passos para a computação sem
auxílio, incluindo a compilação e o teste, é Wallace J. Eckert. O trabalho deste homem antecede a ascensão das
linguagens de computador, porque ele usou a linguagem da matemática para solucionar problemas astronômicos. No
entanto, todos os ingredientes estavam lá: ele trabalhou um laboratório de computação para a Universidade de
Columbia com equipamentos fornecidos pela IBM, completos com uma divisão de serviço de atendimento ao
cliente, e consultores de engenharia para propósitos especiais, na cidade de Nova York, na década de 1930, usando
cartões perfurados para armazenar os resultados intermediários de seus cálculos, e então formatando os cartões
perfurados para controlar a impressão das respostas, igual ao trabalho para os censos décadas antes. Tinha técnicas
de debug tais como códigos de cores, bases cruzadas, verificação e duplicação. Uma diferença entre Eckert e os
programadores dos dias de hoje é que o exemplo do seu trabalho influenciou o projeto Manhattan. Seu trabalho foi
reconhecido por astrônomos do Observatório da Universidade de Yale, Observatório da Universidade de Princeton,
Observatório da Marinha dos EUA, Observatório da Faculdade Harvard, Observatório dos estudantes da
Universidade da Califórnia, Observatório Ladd da Universidade de Brown e Observatório Sproul da Faculdade de
Swarthmore.
87
Alan Turing é frequentemente encarado como o pai da ciência de computadores e, por afinidade, da programação.
Ele foi responsável por ajudar na elaboração e programação de um computador destinado a quebrar o código alemão
ENIGMA durante a Segunda Guerra Mundial — ver Máquina Enigma.
Lista de linguagens
Existem várias linguagens de programação. As 20 mais populares são:[1]
1. Java
2. C
3. C++
4. PHP
5. C#
6. Visual Basic
7. Python
8. Perl
9. Objective-C
10. JavaScript
11. Delphi
12.
13.
14.
15.
16.
17.
18.
19.
20.
Ruby
PL/SQL
SAS
Pascal
Lisp/Scheme/Clojure
MATLAB
ABAP
Lua
PowerShell
[1] Linguagens de programação populares (http:/ / www. tiobe. com/ index. php/ content/ paperinfo/ tpci/ index. html) (em inglês). tiobe.com.
Página visitada em 9 de julho de 2010.
Ver também
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Callback
Ciência de computadores
Falha de segmentação
Lista de linguagens de programação
Orientação a objeto
Programação baseada em ARS
Programação estruturada
Programação funcional
Programação imperativa
Programação em Lógica (Prolog)
Programação orientada por acontecimentos
Software
• Testes de caixa negra
88
Ligações externas
• CS101 Tutorial by Lynn Andrea Stein, Ph.D (http://www.cs101.org/tutorial/index)
• Popular Computer Programming Language Timelines (http://home.cfl.rr.com/eaa/Languages.htm)
• Power Programming Methods (http://www.bitesizeinc.net/power.programming.html)
Teste de Software
O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação ao
contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos.
O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e
que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito.
Visão geral
Não se pode garantir que todo software funcione corretamente, sem a presença de erros,[1] visto que os mesmos
muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanho
do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a
complexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se torna
impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do teste
acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes.[2]
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou
pode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. A
implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é o
resultado de um ou mais defeitos em algum aspecto do sistema.
O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicação
pode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na norma
ISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De forma
geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como especificações,
outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, expectativas do cliente,
normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software diz respeito ao processo de
verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.
Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho. Esta deve ter como
base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estão
definidos os passos necessários para chegar ao produto final esperado.
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um produto
final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.
Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem ter uma metodologia
de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de uma
crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais
pressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazer
com que uma sólida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha
um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia de
software.
89
Teste de Software
Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por
entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e
ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como eficientes,
como por exemplo os SW-CMM, SE-CMM, ISO 15504 e o mais conhecido CMMI.
Outro factor com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes que
serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplina
dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de maneira ineficiente,
seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e
financeiros.
De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhões de
dólares à economia dos Estados Unidos. Mais de um terço do custo poderia ser evitado com melhorias na
infraestrutura do teste de software.[3]
Princípios
Para Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, de
forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente
analisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as
condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a implementação e
para a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de erros, enquanto a
entidade de programação possui uma visão construtiva, em busca da implementação de uma especificação.
Myers também aborda o esforço para se construir casos de teste. Deve-se evitar testes descartáveis, pois a qualidade
do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de regressão, que
permite quantificar a evolução da qualidade de software, mantendo e executando novamente testes realizados
anteriormente.
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência de
erros num certo trecho de código é proporcional à quantidade de erros já encontradas anteriormente. Basicamente,
erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais propensos a ter erros
que outros.
Técnicas
Existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito
utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemas
orientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo
principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas algumas das
técnicas mais conhecidas.
90
Teste de Software
Caixa-branca
Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento interno
do componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software para
avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de caminhos lógicos,
códigos nunca executados.
Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a
construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. O
testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas e
componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubram
todas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas por
estruturas de condições são testadas.
Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de classes de
teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais ou
testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidas
pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidade
de erros de codificação e a busca de utilização de comandos que gerem o melhor desempenho de execução possível.
Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis com essa técnica de teste aplicada sobre
unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado
milhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dos
aparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixar
de atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste de
unidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por
sua vez conhecem bem o código fonte produzido.
Caixa-preta
Também chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avalia
o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo.[4]
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado
previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos
derivados da especificação.
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriam
testadas, mas na ampla maioria dos casos isso é impossível.[5] Outro problema é que a especificação pode estar
ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmas
aceitas para o teste.[6] Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto de
entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadas
similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo
o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis pode
gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificação do sistema,
pode-se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propósito do
sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, o
maior inteiro, o menor inteiro.
Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema e teste de
aceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações de
teste). A aplicação combinada de outra técnica – técnica de particionamento de equivalência (ou uso de classes de
equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes de
equivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destas
91
Teste de Software
classes, de forma que um número mínimo de casos de teste permita a maior cobertura de teste possível.
Uma abordagem no desenvolvimento do teste de caixa-preta é o teste baseado na especificação, de forma que as
funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente para
identificar certos riscos num projeto de software.[7]
Caixa-cinza
A técnica de teste de caixa-cinza é um mesclado do uso das técnicas de caixa-preta e de caixa-branca. Isso envolve
ter acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os caso de teste, que são
executados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é considerado
caixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso de
engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens de
erro.
Regressão
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclo
de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cada
ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nesse
contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela nova
versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada a
utilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes
anteriores possam ser executados novamente com maior agilidade.
Técnicas não funcionais
Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo de acordo com
necessidades de negócio ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, que
verificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam a
operação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar a
tolerância e a robustez do software em lidar com o inesperado.
Uma delas é o uso conjunto de teste de desempenho e teste de carga, que verifica se o software consegue processar
grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina a
escalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é fácil de se
aprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, a
compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.[8] Já o teste de
confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados e
processados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável de
execução após estar em um estado de falha.
92
Teste de Software
93
Fases
Abstração do teste
Descendente
Sistema
Integração
Ascendente
Unidade
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada no
cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste ser
usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o teste
no mesmo momento que o projeto, num processo contínuo até o fim do projeto.
Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil focam o
modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro, por
engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o código é escrito,
passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos junto com o resto do
código fonte do software, e geralmente também integra o processo de construção do software.
Teste de unidade
Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de
software desenvolvidas (pequenas partes ou unidades do sistema).[9] O universo alvo desse tipo de teste são as
subrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentro
de uma pequena parte do sistema funcionando independentemente do todo.
Teste de integração
Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes de
um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente A
pode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornar
um valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outros
sistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério do
gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.
Teste de sistema
Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as
funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições
similares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-dia
de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais de
ambiente, interfaces sistêmicas e massas de dados.
Teste de aceitação
Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulam
operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Teste
formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao cliente
determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo usuário ou por terceira parte,
com o uso de dados ou cenários especificados ou reais. Pode incluir testes funcionais, de configuração, de
recuperação de falhas, de segurança e de desempenho.
Teste de Software
Teste de operação
Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará em
ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de uma
organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem ser
feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes de
instalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará em
produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o suporte ao negócio.
Testes alfa e beta
Em casos especiais de processos de desenvolvimento de software – sistemas operacionais, sistemas gerenciadores de
bancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fases
também especiais antes do produto ser disponibilizado a todos os usuários.
O período entre o término do desenvolvimento e a entrega é conhecido como fase alfa e os testes executados nesse
período, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente do
desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.
Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste do sistema
denominadas versões beta. Ele também é um teste de aceitação voltado para softwares cuja distribuição atingirá
grande número de usuários de uma ou várias empresas compradoras. PRESSMAN afirma que o teste beta é
conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o
desenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação do software num
ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou
imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o
resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois se
preparam para liberar o produto de software para toda a base de clientes.
A comunidade do teste de software usa o termo teste gama de forma sarcástica referindo-se aos produtos que são mal
testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de produção.
Candidato a lançamento
Ultimamente, e principalmente na comunidade de software livre, é comum utilizar o termo candidato a lançamento
(release candidate) para indicar uma versão que é candidata a ser a versão final, em função da quantidade de erros
encontradas. Tais versões são um passo além do teste beta, sendo divulgadas para toda a comunidade.
Papéis
Segue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoa
pode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos de
desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, por
exemplo, os papéis de arquiteto de teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto;
o papel de testador pode ser assumido pelo programador ou por um segundo programador que atue num processo de
programação em pares. Na fase de teste de sistema, num contexto em que haja uma equipe de teste independente,
pode haver profissionais acumulando os papéis de arquiteto de teste, analista de teste e testador.
O líder (ou gerente) do projeto de testes é a pessoa responsável pela liderança de um projeto de teste específico,
normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manutenção. Já o
engenheiro (ou arquiteto) de teste é o técnico responsável pelo levantamento de necessidades relacionadas à
montagem da infraestrutura de teste, incluindo-se o ambiente de teste, a arquitetura de solução, as restrições
tecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pela
comunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).
94
Teste de Software
O analista de teste é o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações do
gerente de teste ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de teste
necessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada. Também no
campo de análise, o analista de ambiente é o técnico responsável pela configuração do ambiente de teste e pela
aplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução e
nos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele será responsável por tornar
disponível o ambiente de teste.
O testador é o técnico responsável pela execução de teste. Ele deve observar as condições de teste e respectivos
passos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuções
de teste mal-sucedidas, esse profissional pode também registrar ocorrências de teste (na maioria das vezes, defeitos)
em canais através dos quais os desenvolvedores tomarão conhecimento das mesmas e tomarão as providências de
correção ou de esclarecimentos.
Por fim, o automatizador de teste é o técnico responsável pela automação de situações de teste em ferramentas. Ele
deve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a
execução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execução
de ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciais
do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)
Artefatos
O processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de uma
referência a um identificador ou requisito de uma especificação, pré-condições, eventos, uma série de passos a se
seguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado obtido. A série de passos (ou parte
dela) pode estar contida num procedimento separado, para que possa ser compartilhada por mais de caso de teste.
Um script de teste é a combinação de um caso de teste, um procedimento de teste e os dados do teste. Uma coleção
de casos de teste é chamada de suite de teste. Geralmente, ela também contém instruções detalhadas ou objetivos
para cada coleção de casos de teste, além de uma seção para descrição da configuração do sistema usado.
A especificação de teste é chamada plano de teste.
[1] MYERS, 2004, p. 8
[2] MYERS, 2004, p. 5
[3] Michael Newman (28 de junho de 2002). Software Errors Cost U.S. Economy $59.5 Billion Annually: NIST Assesses Technical Needs of
Industry to Improve Software-Testing (http:/ / www. nist. gov/ public_affairs/ releases/ n02-10. htm) (em inglês). NIST. Página visitada em 17
de novembro de 2008.
[4] MYERS, 2004, p. 9
[5] MYERS, 2004, p. 10
[6] Jiantao Pan (1999). Software Testing (http:/ / www. ece. cmu. edu/ ~koopman/ des_s99/ sw_testing/ ) (em inglês). Universidade Carnegie
Mellon. Página visitada em 1 de dezembro de 2008.
[7] James Bach (Junho de 1999). Risk and Requirements-Based Testing (http:/ / www. satisfice. com/ articles/ requirements_based_testing. pdf)
(em inglês). IEEE. Página visitada em 17 de novembro de 2008.
[8] MYERS, 2004, p. 136
[9] MYERS, 2004, p. 91
95
Teste de Software
Bibliografia
• KOSCIANSKI, A., Soares, Novatec, M. S. Qualidade de Software, 2006
• PRESSMAN, R. S., McGraw Hill, Engenharia de Software, 2002
• RIOS, E., BASTOS, A., CRISTALLI, R., MOREIRA, T., Martins Fontes, Base de conhecimento em teste de
software, 2007
• MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jérsei: 2004. ISBN ISBN
0-471-46912-2
Ver também
•
•
•
•
•
Anexo:Lista de instituições pela qualidade
Gestão da qualidade
Otimização em engenharia de software.
Ligações externas
• Guia de gerenciamento de teste (http://www.ruleworks.co.uk/testguide)
A documentação de software descreve cada parte do código fonte, geralmente uma função, uma classe, um simples
trecho ou módulo. Consiste também no conjunto de manuais gerais e técnicos, além de diagramas explicando o
funcionamento de um software como um todo ou cada parte dele.
96
Em engenharia de software, manutenção de software é o processo de melhoria e otimização de um software já
desenvolvido (versão de produção), como também reparo de defeitos. A manutenção do software é uma das fases do
processo de desenvolvimento de software, e ocorre a seguir a entrada do software em produção.
Esta fase envolve:
• mudanças no software para corrigir defeitos e deficiências que foram encontrados durante a utilização pelo
usuário
• novas funcionalidades para melhorar a aplicabilidade e usabilidade do software.
A manutenção do software envolve inúmeras técnicas específicas. Uma das técnicas é separação estática, a qual é
usada para identificar todos os códigos de programa que são afetados por alguma variável. Isto é geralmente útil em
programas de refatoração de código que foram especialmente útil em assegurar preparação para bug do milênio.
A fase de manutenção de software é uma parte explicita do modelo em cascata do processo de desenvolvimento de
software a qual foi criada durante a fase de programação estruturada da ciência da computação. O outro modelo
principal, o modelo em espiral, foi desenvolvido durante a fase de orientação ao objeto da engenharia de software,
não faz nenhuma menção explicita a fase de manutenção. Independentemente disto, esta atividade é importante,
considerando o fato que dois terços do custo do tempo de vista do sistema de software envolve manutenções.
No ambiente de desenvolvimento de software formal, a equipe ou organização de desenvolvimento deverá ter algum
mecanismo para documentar e rastrear os defeitos e deficiências. O software é disponibilizado com problemas
porque a organização decide a utilidade e valor do software a um nível de qualidade particular pesando o impacto de
deficiências ou defeitos desconhecidos.
Os problemas conhecidos são normalmente registrados em um documento de considerações operacionais ou notas de
implantação de forma que os usuários do software são capazes de contornar os problemas conhecidos e que irão ser
descobertos quando o uso do software incapacitar tarefas particulares.
Com a implantação do software, outros defeitos e deficiências não documentadas serão descobertos pelos usuários
de software, Tão logo tais problemas sejam reportados para a organização de desenvolvimento, eles passaram a fazer
parte do rastreamento de defeitos do sistema.
As pessoas envolvidas na fase de manutenção de software irão trabalhar no problemas conhecidos, localizá-los, e
preparar novas versões do software, conhecidas como versões de manutenção, a qual ira atualizar a documentação de
problemas.
Ver também
• Software
• Gerenciamento de Projeto
• Fragilidade do software
Ligações externas
•
•
•
•
•
Paper on Software Maintenance Maturity Model [1] (from University of Kentuky)
software manutenção Maturity Model [2]
Paper on Software Maintenance as Part of the Software Life Cycle [3] (da Universidade de Tufts)
Journal of Software Maintenance [4]
Software entropy [5]
97
Referências
[1]
[2]
[3]
[4]
[5]
http:/ / selab. netlab. uky. edu/ homepage/ April%20Huffman%20Abran%20Dumke%20Journal%202005. pdf
http:/ / www. s3m. ca
http:/ / hepguru. com/ maintenance/ Final_121603_v6. pdf
http:/ / www3. interscience. wiley. com/ cgi-bin/ jhome/ 5391/
http:/ / www. pragmaticprogrammer. com/ ppbook/ extracts/ no_broken_windows. html
CMMI
O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou
Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering
(SW), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI
(Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura
estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.
O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto
em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o
desenvolvimento e a manutenção.
A versão atual do CMMI (versão 1.2) apresenta três modelos:
• CMMI for Development (CMMI-DEV) publicada em agosto de 2006. Dirige-se ao processo de desenvolvimento
de produtos e serviços.
• CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos processos de aquisição e
terceirização de bens e serviços.
• CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. Dirige-se aos processos de empresas
prestadoras de serviços.
Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de
uma empresa".
Histórico
Os processos de melhoria nasceram de estudos realizados por Deming (Out of the Crisis), Crosby (Quality is Free:
The Art of Making Quality Certain) e Juran, cujo objetivo principal era a melhoria da capacidade dos processos.
Entende-se por capacidade de um processo a habilidade com que este alcança o resultado desejado.
Um modelo tem como objetivo estabelecer - com base em estudos, históricos e conhecimento operacional - um
conjunto de "melhores práticas" que devem ser utilizadas para um fim específico.
O CMMI tem como origens em três outros modelos de maturidade - SW-CMM (SEI Software CMM), EIA SECM
(Electronic Industries Alliances's Systems Engineer Capability Model) e IPD-CMM (Integrated Product
Development CMM).
98
CMMI
99
Dimensões
O CMM foi construído considerando três dimensões principais: pessoas, ferramentas e procedimentos. O processo
serve para unir essas dimensões.
Disciplinas
O processo inclui três disciplinas ou corpos de conhecimento (body of knowledges), sendo eles:
•
•
•
•
Engenharia de sistemas
Desenvolvimento integrado de produtos e processos (IPPD - Integrated Product and Process Development)
Fontes de abastecimento (Supplier sourcing)
A engenharia de software é similar à engenharia de sistemas em relação às áreas de processo, apenas com enfoque
diferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenharia
de software, mas o nível de maturidade que é diferente.
Representações
O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organização
utilizar diferentes caminhos para a melhoria de acordo com seu interesse.
Representação Continua
Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É
caracterizado por Níveis de Capacidade (Capability Levels):
•
•
•
•
•
•
Nível 0: Incompleto (Ad-hoc)
Nível 1: Executado (Definido)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização (ou Optimizado)
Nesta representação a maturidade é medida por processos separadamente, onde é possível ter um processo com nível
um e outro processo com nível cinco, variando de acordo com os interesses da empresa.
No nível um o processo é executado de modo a completar o trabalho necessário para produzir o trabalho necessário.
Nível dois é sobre planejar a execução e confrontar o executado contra o que foi planejado. No próximo nível o
processo é construído sobre as diretrizes do processo existente, e é mantido uma descrição do processo. O penúltimo
nível é quando o processo é gerenciado quantitativamente através de estatísticas e outras técnicas. No último nível o
processo gerido quantitativamente é alterado e adaptado para atender às necessidades negociais/estratégicas da
empresa.
A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando
já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo
de comparação com outras empresas.
CMMI
100
Representação Por Estágios
Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada,
pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):
•
•
•
•
•
Nível 1: Inicial (Ad-hoc)
Nível 3: Definido
Nível 5: Em otimização
Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os
processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os
processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível de
maturidade três.
Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja
utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de
conhecimento obtido por outros para sua área de atuação.
Áreas de Processo
O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas são
divididas da seguinte forma:
Nível 1: Inicial (Ad-hoc)
Não possui áreas de processo.
•
•
•
•
•
•
•
Gerenciamento de Requisitos - REQM (Requirements Management)
Planejamento de Projeto - PP (Project Planning)
Acompanhamento e Controle de Projeto - PMC (Project Monitoring and Control)
Gerenciamento de Acordo com Fornecedor - SAM (Supplier Agreement Management)
Medição e Análise - MA (Measurement and Analysis)
Garantia da Qualidade de Processo e Produto - PPQA (Process and Product Quality Assurance)
Gerência de Configuração - CM (Configuration Management)
Nível 3: Definido
•
•
•
•
•
•
•
•
•
•
•
Desenvolvimento de Requisitos - RD (Requirements Development)
Solução Técnica - TS (Technical Solution)
Integração de Produto - PI (Product Integration)
Verificação - VER (Verification)
Validação - VAL (Validation)
Foco de Processo Organizacional - OPF (Organizational Process Focus)
Definição de Processo Organizacional - OPD (Organizational Process Definition)
Treinamento Organizacional - OT (Organizational Training)
Gerenciamento Integrado de Projeto - IPM (Integrated Project Management)
Gerenciamento de Riscos - RSKM (Risk Management)
Análise de Decisão e Resolução - DAR (Decision Analysis and Resolution)
• Desempenho de Processo Organizacional - OPP (Organizational Process Performance)
• Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)
CMMI
101
Nível 5: Em otimização
• Inovação Organizacional e Implantação - OID (Organizational Innovation and Deployment)
• Análise Causal e Resolução - CAR (Causal Analysis and Resolution)
Modelos e áreas de processo
As áreas de processo variam com base no modelo escolhido, não sendo as mesmas áreas para todos os modelos
(CMMI-DEV, CMMI-ACQ ou CMMI-SVC).
ISO/IEC 15504
A ISO/IEC_15504, também conhecida como SPICE, define um "processo para relatórios técnicos no assessoramento
em desenvolvimento de software", e similarmente ao CMMI possui níveis de maturidade para cada processo. O
CMMI não é baseado nesta norma, mas sim compatível.
Histórico de Avaliações
Até o ano de 2002, os EUA tinham realizado 1,5 mil avaliações de CMMI, a Índia feito 153, o Reino Unido 103 e o
Brasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcançou o nível 5 em todas as unidades
da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o
nível máximo na avaliação).
Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliações em 1377 organizações. Segue abaixo o
resultado obtido pelas empresas na avaliação (resultados encaminhados para o SEI até 30 de junho de 2006):
•
•
•
•
•
•
18,2%: nível 5 (Optimizing);
4,4%: nível 4 (Quantitatively Managed);
33,8%: nível 3 (Defined);
33,3%: nível 2 (Managed);
1,9%: nível 1 (Initial);
8,4%: sem qualificação (Not Given).
No Brasil, as seguintes empresas conseguiram realizar a certificação até o final, ou seja, alcançaram o nível 5 do
CMMI (por ano da certificação):
2004
• TCS (TATA Consultancy Services) Brazil
2005
• IBM Brazil
• EDS - Electronic Data Systems
• Stefanini IT Solutions
2007
• Ci&T[1]
• CPM Braxis[2]
2009
• Instituto Atlântico[3]
• BRQ IT Services
[1] (http:/ / sas. sei. cmu. edu/ pars/ pars_detail. aspx?a=9167) Ci&T Published Appraisal Results
[2] (http:/ / sas. sei. cmu. edu/ pars/ pars_detail. aspx?a=10163) CPM Braxis Published Appraisal Results
[3] (http:/ / sas. sei. cmu. edu/ pars/ pars_detail. aspx?a=13295) Instituto Atlântico Published Appraisal Results
CMMI
102
Ver também
• Melhoria de Processos de Software Brasileiro (MPS.BR)
Ligações externas
• CMMI Online Browser (http://www.cmmi.de/cmmi_v1.2/browser.html) (em inglês)
• Lista contendo o resultado de todas as empresas avalidas pelo SEI no modelo CMMi (http://sas.sei.cmu.edu/
pars/pars.aspx) (em inglês)
• Lista de Empresas CMMI no Brasil (http://blogcmmi.com.br/avaliacao/lista-de-empresas-cmmi-no-brasil)
(em português)
• Módulos e modelos para CMMI (http://www.sei.cmu.edu/cmmi/models/) (em inglês)
• Blog CMMI (http://www.blogcmmi.com.br) (em português)
• mini CMMI-survey (http://survey.cmmi.hu/). SQI Hungarian Software Quality Consulting Institute Ltd.
(2007). Página visitada em 07 August de 2007.
SPICE
SPICE (acrônimo de Simulated Program with Integrated Circuits Emphasis, ou Programa de Simulação com Ênfase
em Circuitos Integrados) é um software de simulação de circuitos analógicos. É uma poderosa ferramenta usada para
testar, e antever comportamento de circuitos contendo circuitos integrados, resistores, transistores, capacitores,
diodos e outros componentes elétricos e eletrônicos.
História
O software foi desenvolvido no ano de 1975 pelos pesquisadores Larry Nagle e Donald Petterson nos laboratórios de
pesquisas sobre eletrônica da Faculdade de Engenharia Elétrica e Ciências da Computação da Universidade da
Califórnia, campus de Berkeley. Tanto essa versão, como a segunda versão (criada em 1983) foram codificadas
utilizando a linguagem de programação Fortran e rodados em mainframes. A partir da terceira versão, o programa foi
codificado em C, mas utilizando a sintaxe de Fortran para descrever circuitos.
Algumas versões comerciais mantém compatibilidade com a versão de Berkeley, mas outras adcionaram extensões
que incompatibilizou essas versões com a versão de Berkeley. As versões mais recentes incluíram interfaces
gráficas.
Algoritmos diferentes são usados para resolver diferentes tipos de circuitos. Por exemplo, para circuitos não-lineares
(circuitos que possuem elementos não-lineares), é utilizado o método de Newton-Raphson. ...
Versões comerciais
•
•
•
•
•
•
•
PSpice/OrCAD
SPICE OPUS
HSpice (para UNIX)
HSIM
MicroCad
Dr. Spice
T-Spice
• Intusoft
• Spice-It!
• SIMetrix (disponível para Windows e Linux)
SPICE
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
103
TopSPICE
NG-spice
MultiSIM
SmartSpice
TINA
Spectre
Eldo
UltraSim
MacSpice
NanoSim
NSPICE
B2SPICE
ICAP/4
TINA-TI
Proteus ISIS (Labcenter Electronics)
O famoso programa Electronics Workbench também é baseado no SPICE.
Versões Open Source ou Freeware
ngspice [1]
tclspice [2]
LTSpice [3]
Links úteis
Lista de programas de simulação e projeto de circuitos eletrônicos [4]
Referências
[1]
[2]
[3]
[4]
http:/ / ngspice. sourceforge. net/
http:/ / tclspice. sourceforge. net/
http:/ / www. linear. com/ designtools/ software/
http:/ / www. terrypin. dial. pipex. com/ ECADList. html
ISO 12207
ISO 12207
ISO 12207 é uma norma definida pela International Organization for Standardization, que se aplica em engenharia
de software. Esta estabelece um processo de ciclo de vida do software, contendo processos, atividades e são
aplicadas durante a aquisição e configuração dos serviços do sistema, de forma a melhorá-los. Esta norma tem como
principal objetivo fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor,
operador, gerentes e técnicos, envolvidos com o desenvolvimento de software, utilizem uma linguagem comum que
é estabelecida na forma de processos bem definidos.
A estrutura da norma foi concebida de maneira a ser flexível, modular e adaptável às necessidades de quem a utiliza.
Para isso, está fundamentada em dois princípios básicos: modularidade e responsabilidade. Modularidade, no
sentido de processos com mínimo acoplamento e máxima coesão. Responsabilidade, no sentido de estabelecer um
responsável único por cada processo, facilitando a aplicação da norma em projetos, onde várias pessoas podem estar
legalmente envolvidas.
Conforme citado anteriormente, a norma é composta por um conjunto de processos, atividades e tarefas que podem
ser adaptados de acordo com os projetos de software. Estes processos são classificados em três tipos: fundamentais,
de apoio e organizacionais.
Os processos fundamentais são instanciados de acordo com a situação. Enquanto que os processos de apoio e
organizacionais devem existir independentemente da organização e do projeto que está sendo executado.
Basicamente, é correspondido ao ISO 12207.
MPS/Br
O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria
da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do
mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.
Ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro, bem como é
compatível com o CMMI.
No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas
estrangeiras, sendo ideal para micro, pequenas e médias empresas.
Um dos objetivos do projeto é replicar o modelo na América Latina, incluindo o Chile, Argentina, Costa Rica, Peru e
Uruguai.
O projeto tem apoio do Ministério da Ciência e Tecnologia, da FINEP e do Banco Interamericano de
Desenvolvimento. No Brasil o projeto é desenvolvido pela Softex, interagindo com as universidades e com o
Governo Federal.
Motivação
O Brasil é um país cujo desenvolvimento de produtos de software está entre os maiores do mundo, e a cada dia,
aumenta o nível de exigência por parte dos clientes no que diz respeito à qualidade e complexidade dos produtos. A
partir deste ponto, podemos observar que as empresas estão buscando cada vez mais a maturidade nos seus processos
de software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para a
sobrevivência no mercado de TI.
Porém, o custo de uma certificação para uma empresa pode ser de até US$ 400 mil, o que se torna inviável para
empresas de micro, pequeno e médio porte. Então, em uma parceria entre a Softex, Governo e Universidades, surgiu
104
MPS/Br
105
o projeto MPS.Br (melhoria de processo de software brasileiro), que é a solução brasileira compatível com o modelo
CMMI, está em conformidade com as normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira..
O modelo
O MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS.
MR-MPS – Modelo de referência para melhoria do processo de software
O MPS.BR apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que
são:
•
•
•
•
•
•
•
A - Em Otimização;
B - Gerenciado quantitativamente;
C - Definido;
D - Largamente Definido;
E - Parcialmente Definido;
F - Gerenciado;
G - Parcialmente Gerenciado.
Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição,
gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto,
liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de
projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional,
definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto,
análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de
qualidade, gerência de configuração, validação, medição, verificação, treinamento).
Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de
maturação possui um número definido de capacidades a serem vistos.
•
•
•
•
•
•
•
•
•
AP 1.1 - O processo é executado;
AP 2.1 - O processo é gerenciado;
AP 2.2 - Os produtos de trabalho do processo são gerenciados;
AP 3.1 - O processo é definido;
AP 3.2 - O processo está implementado;
AP 4.1 - O processo é medido;
AP 4.2 - O processo é controlado;
AP 5.1 - O processo é objeto de inovações;
AP 5.2 - O processo é otimizado continuamente.
MA-MPS – Método de avaliação para melhoria do processo de software
Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresa
e organizações que implementaram o MR-MPS. Avaliação MA-MPS:
• Equipe de avaliação: 3 a 8 pessoas, sendo:
1 avaliador líder
no mínimo 1 avaliador adjunto
no mínimo 1 técnico da empresa
• Duração: 2 a 4 dias;
• Validade: 3 anos;
MPS/Br
106
Estruturação da Avaliação:
• Planejar e preparar avaliação
Plano de Avaliação / Descrição dos indicadores de processo;
• Conduzir Avaliação
Resultado da avaliação;
• Relatar resultados
Relatório da avaliação;
• Registrar e publicar resultados
Banco de dados Softex (Ver portal MPS.BR nas 'Ligações Externas')
MPS.BR
MN-MPS – Modelo de negócio para melhoria do processo de software
Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar
através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na
experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento
de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de
consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados
no modelo e aprovados em prova específica.
Cursos e certificação
A Softex realiza cursos para formação de consultores, compradores e avaliadores MPS.BR. São ao todo 4 cursos:
•
•
•
•
Curso de Introdução - C1
Curso de Implementação - C2
Curso de Avaliaçao - C3
Curso de Aquisição - C4
Periodicamente, são realizadas provas em nível nacional para certificar profissionais em cada um dos cursos
descritos acima. Tanto os cursos e as provas são realizadas nos Agentes SOFTEX em cada estado, por exemplo:
•
•
•
•
•
•
SOFTEX Campinas (SP)
ITS (São Paulo - SP)
FUMSOFT (Belo Horizonte - MG)
RIOSOFT (Rio de Janeiro - RJ)
SOFTSUL (Porto Alegre - RS)
Entre outras
Próximos passos
O modelo MPS.Br tem como objetivo implementar o Modelo de Referência para melhoria de processo de software
em 120 empresas. E como objetivos secundários, a disseminação em diversos locais do país, capacitação no uso do
modelo e o credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente instituições de
ensino e centros tecnológicos e também a implementação e avaliação do modelo com foco em grupos de empresas.
A avaliação conjunta de grupos empresariais, objetiva a redução dos custos, porém há uma perda de foco, pois não
há uma especificidade para cada empresa e sim um mesmo modelo de referência para todas elas. O MPS.Br já é uma
realidade, e dentro de alguns anos, existe um projeto de implantação em seis países da América Latina, são eles:
Chile, Argentina, Costa Rica, Peru, Uruguai e Cuba.
MPS/Br
Ver também
• CMMI
• CMM
Ligações externas
• Softex - Portal MPS.BR [1]
• Comparação do MPS.Br com o CMMI [2]
Referências
[1] http:/ / www. softex. br/ mpsbr/
[2] http:/ / www. pontodatecnologia. com. br/ 2006/ 08/ comparao-do-mpsbr-com-o-cmmi. html
107
Engenharia de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21853734 Contribuidores: 200.185.142.xxx, 200.222.171.xxx, Abigar, Abmac, Adailton, Alchimista, Alessandro70,
Alexg, André Villeneuve, Arlima, Arthur Buchsbaum, Belanidia, Bonás, Brunoslessa, Chentz, Clayton1975brasilmg, Cuattrin, Daniloleke, Darwinius, Der kenner, Dietox, Ebalter, Eduamaral20,
Engenharia de Software Brasil, Ermeson, FML, Felipe Pinto, Fernando S. Aldado, Furutajp, Gbiten, Get It, Girino, Hgfernan, Hugo Nagatomo, IceMan, Ikarohuhuhu, Inesalegria, Isa.souza,
JaimeChiquita111, Jcmo, Jo Lorib, JoaoMiranda, Jorge, Jorge.roberto, Kyriosdata, Leonardo.stabile, LeonardoG, Lusitana, Luís Felipe Braga, Macau500, Manuel Anastácio, Micato, Miguelcr,
Muriel Gottrop, Nuno Tavares, OS2Warp, PauloColacino, PedroBonifacio, PedroPVZ, Profvalente, Raimundo Norberto, Rbarroso, Rengolin, Rui Silva, Sergio Kaminski, Sica, Teles,
ThiagoRuiz, Tjk4236b, Tonsig, Tumnus, Vigia, Xexeo, ZiroCool, 229 edições anónimas
Software Engineering Body of Knowledge Fonte: http://pt.wikipedia.org/w/index.php?oldid=13869033 Contribuidores: Arlima, Ermeson, Felipe Pinto, Leonardo.stabile, OS2Warp,
Profvalente, Ruy Pugliesi, Xexeo, 3 edições anónimas
Requisitos de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=15720647 Contribuidores: Alcemir felix, Amorujao, AndrelmGomes, Brunosl, Brunoslessa, Eamaral, Flcsilva,
Francisco Leandro, Hgfernan, JoaoRomao, Kim richard, Mrcl, Oalexandrino, Orlando, Rpscampos, Sotu, Steve bruto, Tpa87, Yanguas, 79 edições anónimas
Projeto de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=17890135 Contribuidores: Teste de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21190189 Contribuidores: 333, Adailton, Adersonbs, Alessandro70, Camilor, Cibs, Clara C., Craucarvalho, Daemorris,
Danilo.camargo, Dpc01, Edeunix, Eduacorrea, Eduardoferreira, Fabricioaguirre, Fredxavier, GOE3, GRS73, Girino, Giro720, IceMan, Jic, Josimarp, Lechatjaune, Leobopp, Leonardo.stabile,
Lijealso, Lmozero, Lusitana, Mwaldeck, Nuno Tavares, OS2Warp, Paulo Augusto Nardi, PedroPVZ, Profvalente, Psargaco, Rei-artur, Ricardo.bernardes, Rodrigo Couto e Silva, Rodrigonw,
Sam, Sergio Kaminski, Thevirus, Thiago.jimmy, Thiarlei, Tonsig, Xandi, Xexeo, 151 edições anónimas
Gerência de Configuração de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21738825 Contribuidores: Adailton, Alessandro70, Bisbis, Bjverde, Brunosl, Cledermr, Girino,
Leonardo.stabile, Mwaldeck, OS2Warp, Profvalente, Ricardo.bernardes, 33 edições anónimas
Processos de Engenharia de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=16546588 Contribuidores: Burmeister, Furutajp, 1 edições anónimas
Qualidade de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=13311707 Contribuidores: Adailton, Al Lemos, Alcidesqan, Arlima, Arouck, Bisbis, Brunoslessa, Cidcn,
Eduardoferreira, Felipe Pinto, Fredxavier, Girino, Giro720, Heymar Nunes Jr., Leonardo.stabile, Leonardofp, Luís Felipe Braga, Nice poa, OS2Warp, Pietro Roveri, Rodrigonw, Sedibr, Sergio
Kaminski, Xexeo, 35 edições anónimas
Modelos ciclo de vida Fonte: http://pt.wikipedia.org/w/index.php?oldid=21648855 Contribuidores: 555, Adailton, Alessandro70, Cesar augusto silva, CostaJES, [email protected], Gean,
Julianop, Mecanismo, OS2Warp, Profvalente, Segito, 25 edições anónimas
Análise Estruturada Fonte: http://pt.wikipedia.org/w/index.php?oldid=17057613 Contribuidores: Projeto Estruturado Fonte: http://pt.wikipedia.org/w/index.php?oldid=20890320 Contribuidores: Hermógenes Teixeira Pinto Filho, Reynaldo, 3 edições anónimas
Programação Estruturada Fonte: http://pt.wikipedia.org/w/index.php?oldid=478040 Contribuidores: 200.198.73.xxx, AndrelmGomes, E2mb0t, Get It, GoEThe, Hgfernan, Jorge,
Jorge.roberto, Lcavique, Leonardo.stabile, Moretti, OS2Warp, Ramisses, Wbrito, 13 edições anónimas
Análise Essencial Fonte: http://pt.wikipedia.org/w/index.php?oldid=20787336 Contribuidores: Elvis Pellizari, Reynaldo, Rjclaudio, T.go, 10 edições anónimas
SADT Fonte: http://pt.wikipedia.org/w/index.php?oldid=8418284 Contribuidores: Artdanila, OS2Warp, 3 edições anónimas
DFD Fonte: http://pt.wikipedia.org/w/index.php?oldid=4160520 Contribuidores: Beria, GOE2, JRMarque, John André, OS2Warp, Reynaldo, Sazinho, Tumnus, Zetempesta, 39 edições
anónimas
Modelo de Entidades e Relacionamentos Fonte: http://pt.wikipedia.org/w/index.php?oldid=17057540 Contribuidores: Orientação a Objetos Fonte: http://pt.wikipedia.org/w/index.php?oldid=3899338 Contribuidores: Adailton, Agnaldo.anjos, Albmont, Alchimista, Alexandrepastre, Brunoslessa, ChristianH,
Clara C., Dayane C., Denommus, Denys, Dmendes, Dr.Stefano, Eamaral, Edeyson, FML, FelipeVargasRigo, GOE, GRS73, Gean, Giro720, Herbertdeborba, Hgfernan, Iacobus, Jorge.roberto,
João Carvalho, Juntas, Kelving12, Lampiao, Leandromartinez, Leonardo.stabile, LeonardoG, LeonardoRob0t, Lourenzo, Lucas Avanço, Luís Felipe Braga, Manuel Anastácio, MarceloB, Mauro
Babinski, Nuno Tavares, OS2Warp, Pablodalloglio, Paulo Augusto Nardi, PauloColacino, Rafael.afonso, Rbourdon, Renatoalbano, Rg, Ricvelozo, Rjclaudio, Rlopes, Roma6, Romeuzinh,
Salamat, Santana-freitas, Sica, Tschick, Tumnus, Wanc, Xandi, Xurumelous, Yanguas, Zico Jô, 196 edições anónimas
Rational Unified Process Fonte: http://pt.wikipedia.org/w/index.php?oldid=8461572 Contribuidores: Addycunha, Alcidesqan, Alessandro70, Allanvb, André Villeneuve, Bonás, Brunobaco,
CommonsDelinker, Epinheiro, Felippe Scheidt, GOE2, Gbiten, Get It, Hugo Nagatomo, Infinito, Jbernab, Jphilips, Juntas, Lameiro, Lechatjaune, Leonardo.stabile, LeonardoG, LucianoMaia,
Luís Felipe Braga, M4c0, Manuel Anastácio, Marcelo rodrigues, Mnmadeira, Mwaldeck, Mário e Dário, Ntavares, Nuno Tavares, OS2Warp, Oritemis, PedroPVZ, Pietro Roveri, Profvalente,
RafaAzevedo, Reynaldo, Ricardoroberto, Roberto mms, Rodrigozanatta, Ruy Pugliesi, Servant, Stegop, Villarinho, Wbrito, 209 edições anónimas
Scrum Fonte: http://pt.wikipedia.org/w/index.php?oldid=22025178 Contribuidores: Al Lemos, Bernardovc, Bisbis, Candian, CommonsDelinker, Darwinius, Der kenner, Etore.Santos,
FelipeVargasRigo, Fernandosantucci, Franciosi, Jbernab, Jonilsonfraga, Juukyuu, Leonardo.stabile, M3thos, Marcelloevanessa, Marcio68almeida, Mca.leite, Mwaldeck, OS2Warp, Pietro Roveri,
Porantim, Recoma, Ricardo wellington, Rodm67, Tiago de Jesus Neves, Tiagonmas, Tilgon, Ts42, Vip Ice Man, 95 edições anónimas
Programação extrema Fonte: http://pt.wikipedia.org/w/index.php?oldid=21616816 Contribuidores: 555, Arcanj0, Brunoslessa, Daemorris, DavidFerreira, Dr.Stefano, Dwildt, E2m, Ebalter,
FML, Girino, Ivan Sanchez, Jic, Jorge.roberto, JrBr, Leonardo.stabile, Lijealso, Marcelloevanessa, Marcelo Pinto 70, Mnmadeira, Mwaldeck, Panglossa, Pietro Roveri, Rbarroso, Vinicius.teles,
Wenderf, 78 edições anónimas
Microsoft Solution Framework Fonte: http://pt.wikipedia.org/w/index.php?oldid=18756734 Contribuidores: Hermógenes Teixeira Pinto Filho, Rui Silva, 6 edições anónimas
Diagrama de contexto Fonte: http://pt.wikipedia.org/w/index.php?oldid=20151084 Contribuidores: Belanidia, Chico, Elg, Infinito, Lijealso, Nice poa, Rafaeldapontebarbosa, 11 edições
anónimas
Diagrama de fluxos de dados Fonte: http://pt.wikipedia.org/w/index.php?oldid=4301939 Contribuidores: Beria, GOE2, JRMarque, John André, OS2Warp, Reynaldo, Sazinho, Tumnus,
Zetempesta, 39 edições anónimas
Diagrama entidade relacionamento Fonte: http://pt.wikipedia.org/w/index.php?oldid=20487496 Contribuidores: Bjverde, Danychvaicer, Jml, LauroMoura, Leonardo.stabile, LeonardoG,
Lijealso, Mschlindwein, OS2Warp, Profvalente, Reynaldo, Ricardo Terra, ThiagoRuiz, Xexeo, Yeikicosta, Zeidon, 37 edições anónimas
Dicionário de dados Fonte: http://pt.wikipedia.org/w/index.php?oldid=21277434 Contribuidores: Alquimista Digital, Andrea Bellino, CostaJES, Fredmaranhao, Leonardo.stabile, Silentwarrior,
Tm, 19 edições anónimas
Tabela de decisão Fonte: http://pt.wikipedia.org/w/index.php?oldid=12371732 Contribuidores: Guguff, Jack Bauer00, João Carvalho, 2 edições anónimas
Árvore de decisão Fonte: http://pt.wikipedia.org/w/index.php?oldid=20696945 Contribuidores: Joaopchagas2, João Carvalho, Spoladore, Tilgon, 1 edições anónimas
Diagrama de transição de estados Fonte: http://pt.wikipedia.org/w/index.php?oldid=20689640 Contribuidores: Albertoivo, Chico, DalGond, Darwinius, Hyju, José Roberto A. JR.,
Leonardo.stabile, LeonardoG, Mauro Babinski, Nuno Tavares, O CoRVo, 8 edições anónimas
Processo de desenvolvimento de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21685086 Contribuidores: Alchimista, Alessandro70, Alexanderps, André Villeneuve, Angoti,
Ascn74, Braswiki, Colabardini, Daniloleke, Dvulture, Euclidespaim, FlavioMattos, Gagerred, Girino, Gunnex, Jbernab, Leonardo.stabile, Lourenzo, LucianeOspra, Marlosin, Mwaldeck,
OS2Warp, Pietro Roveri, Pmattos, Profvalente, Rafael R. Faria, Raphaksf, Reynaldo, Rodrigo driessen, Sergio Kaminski, Teles, Tonsig, Utelemaco, Xexeo, 61 edições anónimas
108
Análise de requisitos de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=19859410 Contribuidores: Fernando S. Aldado, Gnramos, Jorgeegpf, Leonardo.stabile, SallesNeto BR, 3
edições anónimas
Especificação de Programa Fonte: http://pt.wikipedia.org/w/index.php?oldid=7082255 Contribuidores: Alessandro70, Leonardo.stabile, Lijealso, Mwaldeck, OS2Warp, 5 edições anónimas
Arquitetura de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=20303533 Contribuidores: Adorilson, Alessandro70, Beria, Hermógenes Teixeira Pinto Filho, Jml, Leonardo.stabile,
Lijealso, Luís Felipe Braga, Maddonde, Mrbar2000, Mwaldeck, Nilo Garcia, Pm wiki, 27 edições anónimas
Programação de computadores Fonte: http://pt.wikipedia.org/w/index.php?oldid=21984206 Contribuidores: 193.126.243.xxx, Ademirfer, Alchimista, Angrense, Bonás, Cavasconcelos, Dante,
the Wicked, Der kenner, Dpc01, Dracom, Dvulture, E2mb0t, Epinheiro, EuTuga, Fanneobom, Fnds, Francisco Paiva Junior, Girino, Gunnex, HecKel, Heldergeovane, Hgfernan, ISoron, Jonas
AGX, Jorge, Jorge.roberto, João Carvalho, Juntas, Leandromartinez, Leonardo.stabile, Luís Felipe Braga, Manuel Anastácio, Marcelloevanessa, Muriel Gottrop, Mwaldeck, Nuno Tavares,
OS2Warp, One People, Onjacktallcuca, Paulorcjr, Pediboi, Petrus Yuri, Pietro Roveri, Reynaldo, Ricardo Augustinis, Ricvelozo, Ronaldocostajr, Suisui, The fabio, TheThingBR, Wbrito,
X360xSilent LightStep, 79 edições anónimas
Teste de Software Fonte: http://pt.wikipedia.org/w/index.php?oldid=3491148 Contribuidores: 333, Adailton, Adersonbs, Alessandro70, Camilor, Cibs, Clara C., Craucarvalho, Daemorris,
Danilo.camargo, Dpc01, Edeunix, Eduacorrea, Eduardoferreira, Fabricioaguirre, Fredxavier, GOE3, GRS73, Girino, Giro720, IceMan, Jic, Josimarp, Lechatjaune, Leobopp, Leonardo.stabile,
Lijealso, Lmozero, Lusitana, Mwaldeck, Nuno Tavares, OS2Warp, Paulo Augusto Nardi, PedroPVZ, Profvalente, Psargaco, Rei-artur, Ricardo.bernardes, Rodrigo Couto e Silva, Rodrigonw,
Sam, Sergio Kaminski, Thevirus, Thiago.jimmy, Thiarlei, Tonsig, Xandi, Xexeo, 151 edições anónimas
Documentação de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=21975352 Contribuidores: Alan ffm, FML, Hgfernan, Leonardo.stabile, Marcelloevanessa, Mwaldeck,
ThiagoRuiz, 2 edições anónimas
Manutenção de software Fonte: http://pt.wikipedia.org/w/index.php?oldid=20300517 Contribuidores: Al Lemos, Alessandro70, Beetstra, Girino, Leonardo.stabile, Mwaldeck, Profvalente, 6
edições anónimas
CMMI Fonte: http://pt.wikipedia.org/w/index.php?oldid=21840139 Contribuidores: Brunoslessa, Chentz, ChristianH, Dayane C., Dobau, Dreispt, Dwandarti, Eugeniomartins, Felipe Pinto,
Fernando S. Aldado, Flávio Costa, GOE, Galabriel, Gus W, H3rman, Itras, Leonardo.stabile, Mestre Yoda, Mwaldeck, OS2Warp, Onjacktallcuca, Pietro Roveri, Porantim, Rcsilva83, Rei-artur,
Ronaldofiorilo, Villarinho, 69 edições anónimas
SPICE Fonte: http://pt.wikipedia.org/w/index.php?oldid=20429098 Contribuidores: Alves, Euclidespaim, Frosseto, Hyju, Josepojr, Leonardo.stabile, Luiz Jr, RenanBirck, Tschulz, 4 edições
anónimas
ISO 12207 Fonte: http://pt.wikipedia.org/w/index.php?oldid=21049131 Contribuidores: Adamlorenz, Gaguigu, Gildemax, Ikescs, Jurema Oliveira, Luís Felipe Braga, Manuel Anastácio,
MarioM, Mosca, Pedro.haruo, Sadoc, 12 edições anónimas
MPS/Br Fonte: http://pt.wikipedia.org/w/index.php?oldid=10205112 Contribuidores: Arges, Brandizzi, Chentz, Felipe Pinto, Fernando Colares, Fredxavier, Gunnex, Jcgpereira2001,
Leonardo.stabile, Lijealso, Luís Felipe Braga, Nice poa, OS2Warp, Tiago.bn, Xexeo, 38 edições anónimas
109
Ficheiro:Crystal Clear action 1downarrow.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Crystal_Clear_action_1downarrow.png Licença: desconhecido Contribuidores: Abu
badali, Augiasstallputzer, CyberSkull, Foroa, Juliancolton, Rocket000, 6 edições anónimas
Ficheiro:Crystal Clear action 1uparrow.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Crystal_Clear_action_1uparrow.png Licença: desconhecido Contribuidores: Abu
badali, Augiasstallputzer, CyberSkull, Rocket000
Imagem:cquote1.svg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote1.svg Licença: Public Domain Contribuidores: Adambro, Editor at Large, Infrogmation, P 96glin, 1
edições anónimas
Imagem:cquote2.svg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote2.svg Licença: Public Domain Contribuidores: Editor at Large, Infrogmation
Imagem:Processo_es.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Processo_es.jpg Licença: Public Domain Contribuidores: User:Furutajp
Imagem:coarse grain.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Coarse_grain.jpg Licença: GNU Free Documentation License Contribuidores: LeonardoG
Imagem:waterfall diagram.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Waterfall_diagram.jpg Licença: GNU Free Documentation License Contribuidores: Original
uploader was [email protected] at pt.wikipedia
Ficheiro:Modelos da analise essencial.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Modelos_da_analise_essencial.png Licença: Creative Commons Attribution-Sharealike
3.0 Contribuidores: Elvis Pellizari
Ficheiro:Diagrama de contexto.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Diagrama_de_contexto.png Licença: Creative Commons Attribution-Sharealike 3.0
Contribuidores: Elvis Pellizari
Ficheiro:Simbologia analise essencial.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Simbologia_analise_essencial.png Licença: Creative Commons Attribution-Sharealike 3.0
Contribuidores: Elvis Pellizari
Imagem:Dfd.JPG Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Dfd.JPG Licença: Public Domain Contribuidores: Mtheus, Newmanbe
Arquivo:Scrum process.svg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Scrum_process.svg Licença: GNU Free Documentation License Contribuidores: Lakeworks, Mdd,
Sebastian Wallroth, 1 edições anónimas
Imagem:Tabeladecisao.JPG Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Tabeladecisao.JPG Licença: Public Domain Contribuidores: 555, Mtheus
Imagem:Arvoredecisao.JPG Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Arvoredecisao.JPG Licença: Public Domain Contribuidores: Mdd, Mtheus
Ficheiro:semaforo.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Semaforo.jpg Licença: Public Domain Contribuidores: Smartkids
Ficheiro:Transicaoestado.JPG Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Transicaoestado.JPG Licença: Public Domain Contribuidores: Mtheus
Ficheiro:Primoc.png Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Primoc.png Licença: Creative Commons Attribution-Sharealike 2.5 Contribuidores: Meno25, Paulorcjr,
WikipediaMaster, 2 edições anónimas
File:H96566k.jpg Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:H96566k.jpg Licença: Public Domain Contribuidores: Courtesy of the Naval Surface Warfare Center, Dahlgren,
VA., 1988.
110
Licença
Licença
Creative Commons Attribution-Share Alike 3.0 Unported
http:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/
111

Engenharia de Software

Transcrição

Documentos relacionados

ORGANOGRAMA FUNDEP

RUP Rational Unified Proccess (Processo Unificado da Rational)

Baixar o arquivo - instituto aphomoioo

Processos de Software: Conceitos Básicos - LES PUC-Rio

anexo ii - departamento de compras – dcom

Ficha técnica Bombona 20 litros

Coordenador de QSMS RD QSMS

Texto 02

História da arquitetura

Como á imos em aulas anteriores, as tentati as de compreensão de