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

Engenharia de SoftwareMetodologias de Desenvolvimento deSistemas

ConteúdoPáginas

Engenharia de software 1Software Engineering Body of Knowledge 8Requisitos de Software 9Projeto de Software 18Teste de software 18Gerência de Configuração de Software 25Processos de Engenharia de Software 34Qualidade de Software 36Modelos ciclo de vida 39Análise Estruturada 43Projeto Estruturado 43Programação Estruturada 44Análise Essencial 44SADT 48DFD 48Modelo de Entidades e Relacionamentos 49Orientação a Objetos 49Rational Unified Process 52Scrum 60Programação extrema 64Microsoft Solution Framework 67Diagrama de contexto 71Diagrama de fluxos de dados 71Diagrama entidade relacionamento 72Dicionário de dados 73Tabela de decisão 74Árvore de decisão 75Diagrama de transição de estados 75Processo de desenvolvimento de software 77Análise de requisitos de software 81Especificação de Programa 81Arquitetura de software 82Programação de computadores 86Teste de Software 89

Documentação de software 96Manutenção de software 97CMMI 98SPICE 102ISO 12207 104MPS/Br 104

ReferênciasFontes e Editores da Página 108Fontes, Licenças e Editores da Imagem 110

Licenças das páginasLicença 111

Engenharia de software 1

Engenharia de softwareEngenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimentoe 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 quepermitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindosuas qualidades. Além disso, a engenharia de software deve oferecer mecanismos para se planejar e gerenciar oprocesso de desenvolvimento de um sistema de informação Sistema computacional, pois ambos se confundem!

DefiniçãoFriedrich Ludwig Bauer foi o primeiro a defini-la como sendo: "Engenharia de Software é a criação e a utilização desólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalheeficientemente 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 aciê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 SoftwareEngineering (Conferência sobre Engenharia de Software da OTAN). Sua criação surgiu numa tentativa de contornara crise do software e dar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento desistemas de software complexos. Um sistema de software complexo se caracteriza por um conjunto de componentesabstratos 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 emsistemas computacionais.Os fundamentos científicos envolvem o uso de modelos abstratos e precisos que permitem ao engenheiroespecificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Alémdisto, deve oferecer mecanismos para se planejar e gerenciar o processo de desenvolvimento. Empresasdesenvolvedoras de software passaram a empregar esses conceitos sobretudo para orientar suas áreas dedesenvolvimento, 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 emcomputadores, incluindo hardware e engenharia de processos além do software.

Áreas de ConhecimentoSegundo o SWEBOK (Corpo de Conhecimento da Engenharia de Software), versão 2004, as áreas de conhecimentoda 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

Engenharia de software 2

• Processos de Engenharia de Software• Ferramentas e Métodos de Engenharia de Software• Qualidade (Quality) de SoftwareConforme 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, é interessanteestudarmos a ES em suas camadas de Processo, Métodos e Ferramentas.

Processo de SoftwareProcesso de software, ou processo de engenharia de software, é uma seqüência coerente de práticas que objetiva odesenvolvimento 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 é umacontinuaçã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 ooriginal em inglês design.

Modelos de Processo de SoftwareUm modelo de processo de desenvolvimento de software, ou simplesmente modelo de processo, pode ser visto comouma representação, ou abstração dos objetos e atividades envolvidas no processo de software. Além disso, ofereceuma forma mais abrangente e fácil de representar o gerenciamento de processo de software e consequentemente oprogresso 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.

Engenharia de software 3

Modelos de MaturidadeOs modelos de maturidade são um metamodelo de processo. Eles surgiram para avaliar a qualidade dos processos desoftware aplicados em uma organização (empresa ou instituição). O mais conhecido é o Capability Maturity ModelIntegration (CMMi), do Software Engineering Institute - SEI.O CMMi pode ser organizado através de duas formas: Contínua e estagiada. Pelo modelo estagiado, mais tradicionale 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çãoque foram dadas ao seu predecessor, o CMM.O (MPS.BR), ou Melhoria de Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria eum modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas dedesenvolvimento de software no Brasil.

Metodologias e MétodosO 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 umametodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticasdiferenciadas para realizar algo.[1]

Assim teríamos, por exemplo, a Metodologia Estruturada, na qual existem vários métodos, como Análise Estruturadae Projeto Estruturado (muitas vezes denominados SA/SD, e Análise Essencial). Tanto a Análise Estruturada quanto aAná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

Engenharia de software 4

• Microsoft Solution Framework ( MSF )

ModelagemA abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para oentendimento 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 acomplexidade (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áticasA engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência dacomputaçã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

FerramentasOutro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essaclassificaçã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

Engenharia de software 5

Gerência de ProjetosA gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitosestabelecidos, 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 comprocesso de desenvolvimento com baixa padronização.

PlanejamentoO 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 custosEssas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear emrelação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado denovos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramentea produtividade.A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemasté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 riscosnecessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.

Análise de RequisitosAs atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema desoftware. 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 hajamudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características desistemas 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 documentode requisitos de sistema (SOMMERVILLE). Segundo RUMBAUGH, alguns analistas consideram a engenharia deRequisitos como um processo de aplicação de um método estrutura como a analise orientada a objetos. No entanto, aEngenharia 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 deRequisitos"

Engenharia de software 6

O primeiro processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os resultados deste processodevem ser um relatório com as recomendações da viabilidade técnica ou não da continuidade no desenvolvimento doSistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido, deverá abordarfundamentalmente as seguintes questões:O Sistema proposto contribui para os objetivos gerais da organização? O Sistema poderá ser implementado com astecnologias 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óricoA Engenharia de Software (ES) surgiu em meados dos anos 1970 numa tentativa de contornar a crise do software edar um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento de sistemas de softwarecomplexos. 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 agentesinterconectados entre si, compondo a arquitetura do software, que deverão ser executados em sistemascomputacionais.

ES no Presente e TendênciasAtualmente existe um destaque todo especial para a Engenharia de Software na Web. Também utilizado porPresmann 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, existempeculiaridades 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, maiorimportâ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 aresolução de diversos problemas da área. A área, denominada Search-based software engineering, ou Otimização emengenharia 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%20Revisão%20de%20Literatura%20%28Otimização%20em%20Engenharia%20de%20Software%29.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 daEngenharia de Software: Revisão de Literatura (http:/ / goes. comp. uece. br/ resources/ Search-based Software Engineering - Aplicação deMetaheurísticas em Problemas da Engenharia de Software Revisão de Literatura (Otimização em Engenharia de Software). pdf), II CongressoTecnológico Infobrasil, 2009,

Engenharia de software 7

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 dedesenvolvimento 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 deInformática --- Universidade Federal de Goiás.

• GPES (http:/ / www. gpes. dcc. ufmg. br/ ) Grupo de Pesquisa em Engenharia de Software do Departamento deCiê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• Software Engineering Body of Knowledge• Análise Econômica de Sistemas de Informações• Matriz CRUD• Otimização em engenharia de software

Software Engineering Body of Knowledge 8

Software Engineering Body of KnowledgeO Guide to the Software Engineering Body of Knowledge, conhecido pela sigla SWEBOK, é um documentocriado sob o patrocínio da IEEE com a finalidade de servir de referência em assuntos considerados, de formageneralizada 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ívelmais 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• Requisitos de Software• Projeto de Software• Construção de Software• Teste de Software• Manutenção de Software• Gerência de Configuração de Software• Gerência da Engenharia de Software• Processo de Engenharia de Software• Ferramentas e Métodos da Engenharia de Software• Qualidade 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

Software Engineering Body of Knowledge 9

CríticaComo toda classificação hierárquica, foram tomadas decisões específicas sobre em que posição da hierarquia ostó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

Requisitos de SoftwareA engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as atividadesque 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. Identificação.2. Análise e negociação.3. Especificação e documentação.4. 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 queas alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na naturezado negócio (e consequentemente nos requisitos), entre outras).

Estudos de viabilidadeAntes de se avançar com uma análise mais detalhada dos requisitos de um projeto, deve ser feito um estudo deviabilidade.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" (oustakeholder 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?

Requisitos de Software 10

A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhetraz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvia, sãofrequentemente desenvolvidos sistemas que não contribuem para os objetivos das respectivas organizações, quer sejapor interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos daorganização.Deve portanto identificar-se que informação é necessária para responder a estas questões e quem possui estainformação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbitodo projeto e avaliar a sua viabilidade.Tipicamente, quem poderá fornecer esta informação serão os utilizadores dos sistemas atuais e do sistema aimplementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejamfamiliarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pelamanutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interaçãocom 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 dodesenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projetoe definindo mesmo alguns requisitos de alto nível.

IdentificaçãoCaso se determine que o projeto é viável, o passo seguinte é a identificação dos requisitos.

Atividades envolvidasAlgumas 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 oanalista e as partes interessadas.

• Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porémpara 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 osistema.

• Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve serconsensual) e devem ser propostas soluções em conjunto com as partes interessadas.

Requisitos de Software 11

DificuldadesEsta 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 requisitosExistem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situações, entre as quaispodemos citar:

Entrevistas e Questionários

Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa faseinicial 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 fazerparte um grupo de analistas e um grupo representando o cliente[2] , para então obter um conjunto de requisitosbem definidos. Ao contrário das reuniões, promove-se a interação entre todos os elementos presentes noworkshop fomentando momentos de descontração como forma de dinamizar o trabalho em equipe, existindo umfacilitador neutro cujo papel é conduzir o workshop e promover a discussão entre os vários intervenientes (aindaque não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos edevem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil emworkshops é o uso de brainstorming (tempestade de idéias) como forma de gerar um elevado número de ideiasnuma pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflitaos requisitos e decisões tomadas sobre o sistema a implementar.

Requisitos de Software 12

Cenários

• Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através deexemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca doseu comportamento e da interação que esperam ter com ele. Trata-se de uma abordagem informal, prática eaplicá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 naidentificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda poucodefinidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tãofacilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendonormalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhepodem 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álisecusto-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendoparticularmente ú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 emarticular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de umaobservação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrarrequisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada deregistros áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar podeser 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 requisitosApós a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos.

Atividades envolvidasAlgumas 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; é importanteresolver 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).

Requisitos de Software 13

Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir inclusive para asdemais fases.A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio dofuturo sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cadaciclo de trabalho.

DificuldadesAs 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 pontode 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, osrequisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas sãoenvolvidas no projeto, ou alterações em prazos e orçamentos disponíveis).

NegociaçõesRelativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra sem problemas, chegando-selogo 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 qualo sistema será desenvolvido.

• Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistemadeve 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 denecessidades 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 distinguirtrê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 secomunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando "linguagens" queo utilizador conheça). Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de altonível das funcionalidades do sistema e suas restrições, usando linguagem natural e eventualmente diagramas

Requisitos de Software 14

(esquemas), nos requisitos do sistema cada requisito é descrito com mais detalhe introduzindo já alguns conceitosrelativos à arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notações gráficos como diagramas decasos de uso).

Requisitos do utilizadorOs requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistemaserá 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 surgemalgumas 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 deixarclaro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressõesde 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 sistemaOs requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos doutilizador correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e notaçõesgráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros quetrabalhem nessa organização) e destinam-se também às equipes de especificação de arquitetura do sistema e dedesenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, emboraalguns 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çãoPor fim, a especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento dosistema no qual estão definidos pormenores, em um nível mais técnico, acerca da implementação do sistema e suaarquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projetodeverá ser capaz de "se situar" quando precisar de começar a codificar, compreendendo a forma como aimplementação, em um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes deimplementação aprofundados. Não convém cair na tentação de deixar toda a implementação detalhada, uma vez queconvém que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolverproblemas encontrados em sub-sistemas de formas que uma especificação inicial da arquitetura não consegue prever.

Requisitos de Software 15

Documento de Especificação de RequisitosApesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação que é a usadacomo declaração oficial dos requisitos do sistema.Este documento, normalmente chamado de Documento de Especificação de Requisitos (Software RequirementsSpecification ou SRS) inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidadespara 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 estruturaproposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-1993 (Thayer e Dorfman, 1993).

ValidaçãoNesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que ocliente 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 encontradosdemasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitostêm repercussões proporcionais à dimensão do projeto. Uma vez que alterações em requisitos já consolidados têmum custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos enecessidade 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 dosrequisitos:• 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) podemdiferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada clientecompreenda 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 sistemafinal corresponde à especificação inicial.

• Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outrosmotivos, 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.

Requisitos de Software 16

Técnicas de validaçãoPara 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 estacorresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter umaconversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitosproduzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios quetodos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadoresfinais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofreralteraçõ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 osutilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão maiscontacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempogasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com aversão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cairna tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo devaser 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 fasede validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil eque 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 asferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testadanesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas.

RecomendaçõesA fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito importante na engenharia derequisitos 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 adiscordâ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 requisitosOs 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 definidoantes 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çõestecnológicas ou alterações na organização na qual é usado).É natural que surjam requisitos por parte dos utilizadores por diversos motivos:

Requisitos de Software 17

• Conforme já foi referido, a resolução de conflitos entre requisitos resulta num compromisso que procuraequilibrar as necessidades das diferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com ouso do sistema é que é possível avaliá-lo convenientemente. Para além de conflitos entre requisitos de diferentesutilizadores do sistema, há ainda a considerar os conflitos entre utilizadores e "elementos executivos" daorganização, isto é, aqueles que têm o poder de decisão e que podem impôr requisitos perante os analistas (quepodem 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 causaalguns dos requisitos do sistema, alterações a nível tecnológico podem surgir na organização (afectandoparticularmente, no caso de alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemasque precisem de suporte, a nível de interação, por parte do sistema implementado, e toda uma série de alteraçõesimprevisí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 daentidade 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 parteimportante 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 eassociaçã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 ouso 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 asseguintes 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çãodirectamente e só depois, retrospectivamente, actualizar os requisitos pode levar a dessincronização entre requisitos eimplementaçã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

Requisitos de Software 18

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.

FerramentasProjeto SER::Sistema de Engenharia de Requisitos (https:/ / sourceforge. net/ p/ sersistemadeeng)

Projeto de Software1. REDIRECIONAMENTO Projeto de software

Teste de softwareO teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação aocontexto 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, eque envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito.

Visão geralNão se pode garantir que todo software funcione corretamente, sem a presença de erros,[1] visto que os mesmosmuitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanhodo projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais acomplexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se tornaimpossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do testeacaba 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, oupode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. Aimplementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é oresultado 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çãopode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na normaISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De formageral, 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 deverificaçã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

Teste de software 19

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 produtofinal 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 metodologiade trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de umacrescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez maispressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazercom 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 obtenhaum produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia desoftware.Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos porentidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações eambientes 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 queserão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplinadedicada 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 efinanceiros.De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhões dedólares à economia dos Estados Unidos. Mais de um terço do custo poderia ser evitado com melhorias nainfraestrutura do teste de software.[3]

PrincípiosPara Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, deforma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamenteanalisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também ascondições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a implementação epara a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de erros, enquanto aentidade 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 qualidadedo teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de regressão, quepermite quantificar a evolução da qualidade de software, mantendo e executando novamente testes realizadosanteriormente.O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência deerros 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 errosque outros.

Teste de software 20

TécnicasExistem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muitoutilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemasorientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivoprincipal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas algumas dastécnicas mais conhecidas.

Caixa-brancaTambém chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento internodo componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software paraavaliar 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 aconstrução do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. Otestador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas ecomponentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubramtodas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas porestruturas 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 deteste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais outestes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidaspelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidadede 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 sobreunidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executadomilhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dosaparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixarde atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste deunidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que porsua vez conhecem bem o código fonte produzido.

Caixa-pretaTambém chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avaliao 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 esperadopreviamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todosderivados 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

Teste de software 21

sistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, omaior 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 deaceitação. A aplicação de técnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situações deteste). A aplicação combinada de outra técnica – técnica de particionamento de equivalência (ou uso de classes deequivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. A partir das classes deequivalência identificadas, o testador construirá casos de teste que atuem nos limites superiores e inferiores destasclasses, 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 asfuncionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente paraidentificar certos riscos num projeto de software.[7]

Caixa-cinzaA técnica de teste de caixa-cinza é um mesclado do uso das técnicas de caixa-preta e de caixa-branca. Isso envolveter acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os caso de teste, que sãoexecutados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é consideradocaixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso deengenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens deerro.

RegressãoEssa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclode teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cadaciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nessecontexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela novaversão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada autilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testesanteriores possam ser executados novamente com maior agilidade.

Técnicas não funcionaisOutras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo de acordo comnecessidades de negócio ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, queverificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam aoperação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar atolerâ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 processargrandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina aescalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é fácil de seaprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, acompreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.[8] Já o teste deconfiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados eprocessados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável deexecução após estar em um estado de falha.

Teste de software 22

Fases

Abstração do teste

Descendente Sistema

AscendenteIntegração

Unidade

Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada nocliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste serusada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o testeno 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 omodelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro, porengenheiros 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 docódigo fonte do software, e geralmente também integra o processo de construção do software.

Teste de unidadeTambém conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades desoftware desenvolvidas (pequenas partes ou unidades do sistema).[9] O universo alvo desse tipo de teste são assubrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentrode uma pequena parte do sistema funcionando independentemente do todo.

Teste de integraçãoNa fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes deum sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente Apode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornarum valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outrossistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério dogerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.

Teste de sistemaNa fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo asfuncionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condiçõessimilares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-diade manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais deambiente, interfaces sistêmicas e massas de dados.

Teste de aceitaçãoGeralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulamoperações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Testeformal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao clientedeterminar 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, derecuperação de falhas, de segurança e de desempenho.

Teste de software 23

Teste de operaçãoNessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará emambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de umaorganização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem serfeitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes deinstalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará emproduçã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 debancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fasestambé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 nesseperíodo, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente dodesenvolvedor, 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 sistemadenominadas 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, odesenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação do software numambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ouimaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com oresultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois sepreparam 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 maltestados 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 errosencontradas. Tais versões são um passo além do teste beta, sendo divulgadas para toda a comunidade.

PapéisSegue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoapode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos dedesenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, porexemplo, 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 deprogramaçã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á oengenheiro (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çõestecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pelacomunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).

Teste de software 24

O analista de teste é o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações dogerente de teste ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de testenecessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada. Também nocampo de análise, o analista de ambiente é o técnico responsável pela configuração do ambiente de teste e pelaaplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução enos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele será responsável por tornardisponí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 respectivospassos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuçõesde 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 decorreçã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. Eledeve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar aexecução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execuçãode ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciaisdo ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)

ArtefatosO processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de umareferência a um identificador ou requisito de uma especificação, pré-condições, eventos, uma série de passos a seseguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado obtido. A série de passos (ou partedela) 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çãode casos de teste é chamada de suite de teste. Geralmente, ela também contém instruções detalhadas ou objetivospara 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 17de 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

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• Qualidade de software• 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 SoftwareGerência de Configuração de Software, Gerência de Configuração ou ainda Gestão de Configuração deSoftware é uma área da engenharia de software responsável por fornecer o apoio para o desenvolvimento desoftware. Suas principais atribuições são o controle de versão, o controle de mudança e a auditoria dasconfigurações.Roger Pressman, em seu livro Software Engineering: A Practitioner's Approach, afirma que a gerência deconfiguraçã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 destesprodutos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.

— RogerPressman

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 osmotivos a cada uma das mudanças. A Auditoria por sua vez responde as duas últimas perguntas: Quem fez amudança e podemos reproduzir a mudança?

Gerência de Configuração de Software 26

HistóricoA história da Gerência de Configuração de Software surge em meados da década de 1970, quando osmicroprocessadores se tornaram populares e o software deixou de ser considerado parte integrante do hardware parase tornar um produto independente. Nesta época, os sistemas se tornaram cada vez maiores e sofisticados, ficandoclaro que seriam necessárias metodologias próprias, diferentes das usadas no desenvolvimento de hardware, paracontrolar o desenvolvimento desses sistemas.O Departamento de Defesa (DoD) dos EUA foi um dos pioneiros nessa área, criando o padrão DoD-STD-2167 queabordava o desenvolvimento de software. A abordagem do DoD para controlar isto consistia da adoção de umalinguagem 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 governoAmericano. Isto levou o próprio DoD a adotar algumas práticas comerciais e eventualmente uni-las com seuspadrões, gerando assim o padrão IEEE/IEA 12207. Um outro padrão a respeito é o IEEE 828-1983.

FunçõesA Gerência de Configuração de Software é definida por quatro funções básicas:[1]

• Identificação• Documentação• Controle• AuditoriaNo início do desenvolvimento, a GCS permite à equipe de desenvolvimento identificar as unidades que compõem osistema 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 interfacespermite que a integração entre estas unidades tenha sucesso continuado, com as mudanças devidamente gerenciadase documentadas. Por fim, a auditoria das funcionalidades identificadas, documentadas e controladas garante aconfiabilidade do sistema.

Conceitos e TerminologiaA terminologia especifica da GCS, como também sua história, tem dado origem a controvérsias, de freqüentesvariações. Ferramentas vendidas como também acadêmicas tiraram vantagem disto para deliberadamente mudar aterminologia ou procedimentos para reduzir a possibilidade dos clientes para mudanças, algumas vezes tentandodesta maneira redefinir o estabelecimento de acrônimos.Em particular, o vendedor conhecido como Atria (depois Rational Software), agora uma parte da IBM, usava SCMcomo 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 fornecedorpara o outro meramente nos termos utilizados.

Gerência de Configuração de Software 27

Configuração de softwareConfiguração é o estado em que um sistema se encontra em um determinado momento. Este sistema pode sercomposto de todo tipo de elementos, como peças de hardware, artefatos eletrônicos ou não (i.e. documentos empapel), etc. A Configuração de Software trata apenas dos elementos que se encontram em formato eletrônico efazem parte dessa configuração. Isso inclui todos os arquivos fontes, todos os documentos eletrônicos, asferramentas de software utilizadas para construir ou mesmo ler estes arquivos, o sistema operacional utilizado, asbibliotecas de software, etc.Essa configuração varia com o tempo, pois novos arquivos são incluídos, e arquivos existentes são alterados ouremovidos. O objetivo da Gerência de Configuração como um todo é organizar todos estes elementos de forma asaber em qual estado o sistema se encontrava nos momentos chave do desenvolvimento (por exemplo, quando osistema foi entregue ao cliente, quando o sistema passou por uma mudança de versão, quando o sistema foi enviadopara auditoria, etc). A Gerência de Configuração como um todo trata dos elementos, incluindo hardware, necessáriospara a manutenção apropriada do sistema. a Gestão de Configuração de Software trata especificamente doselementos necessários a construção de sistemas de software, e em geral, controla apenas os elementos em formatocomputadorizado.Em Sistemas de controle de versão as configurações específicas são geralmente identificadas pelo uso de tags oulabels (placas ou etiquetas, em inglês).

Linha-baseLinhas-base ou Baseline é um conceito de gerenciamento de configuração de software que nos ajuda a controlar asmudanças, sem impedir seriamente as mudanças justificáveis. Segundo PRESSMAN no contexto de engenharia desoftware, 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) epela 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 americanoEm Sistemas de controle de versão uma linha-base é geralmente identificada pelo uso de branches (galhos, eminglês).

Item de configuração de softwareDurante o desenvolvimento de software, uma grande quantidade de informações é produzida e cada um dessesdocumentos produzidos que precisam sofrer controle de versões e de mudanças é chamado de item de configuraçãode software O Item de configuração é um elemento unitário que será gerenciado: um arquivo de código fonte, umdocumento de texto, um projeto de uma placa eletrônica, uma planta feita em papel, um CD-ROM de instalação deum sistema operacional, etc. A configuração de um sistema é basicamente a lista de todos os itens de configuraçãonecessários para reproduzir um determinado estado de um sistema. Em geral números de versão são associados aositens 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.0e assim por diante.

Gerência de Configuração de Software 28

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 doprojeto modular; d) Descrições do projeto de interfaces; e) Descrições de objetos (no caso do uso da metodologiaOO).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) Pedidosde mudança de engenharia.13. Padrões e procedimentos para engenharia de software.

Identificação de objetosDefinimos CSI, no mecanismo de identificação de gerenciamento de configurações, como sendo a sua entidade maiselementar.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, umalista 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.

Gerência de Configuração de Software 29

Controle de versõesOcorrem muitos problemas durante o desenvolvimento de software que são causados por falta de controle sobre osarquivos 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 oseu 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 seguintesfuncionalidades:• 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 projetoControle de Versão resolve diversos problemas básicos de desenvolvimento tais como uso de diferentes versões decódigo, sincronização do trabalho paralelo de desenvolvedores no mesmo projeto, recuperação de versões anteriorese 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 rotinapara otimizar uma consulta, se você inseriu uma nova função e retirou outra, se você modificou a imagem que eraexibida em determinada página html, tudo fica guardado neste histórico. Para que isso? Para o caso de sua alteraçãocausar algum problema! Se deu você nem precisa se preocupar em relembrar o que foi que tinha alterado, se fez tudocorreto, 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ãonum local denominado de repositório, lugar onde se guarda, arquiva, coleciona alguma coisa. É o local onde você vaiguardar o seu projeto. Na prática, é um diretório, uma pasta qualquer guardada ou no seu computador, ou no seupendrive. O repositório registra cada alteração realizada em cada arquivo e diretório controlado. À medida que oprojeto evolui, o repositório passa a guardar múltiplas versões dos arquivos que compõem o projeto. Essas múltiplasversões são organizadas em revisões. Uma revisão funciona como um clone de todos os arquivos do projeto em umdeterminado momento do tempo. Os clone antigos são mantidos e podem ser recuperados e analisados a qualquermomento. 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 acordocom a revisão desejada. Mesmo que não haja alteração em um arquivo entre uma revisão e outra, o número darevisão do arquivo acompanha o número da revisão global, de modo a manter sempre um grupo coeso e coerente dearquivos.

Gerência de Configuração de Software 30

Diferentes versões de projeto

Alguns projetos precisam de variações específicas, conforme as necessidades específicas de cada cliente, ou criaçãode um ramo para experimentações no projeto, sem comprometer a linha principal de desenvolvimento. O sistema decontrole de versão oferece funcionalidades que facilitam a coordenação de ramos diferentes de desenvolvimento emum mesmo projeto. As alterações feitas em um ramo muitas vezes precisam ser mescladas em outro ramo. Essaoperação é bastante delicada e é facilitada em muito com o sistema de controle de versão, que permite bastantecontrole e automação no processo. Mesmo em caso de uma fusão mal-sucedida, o sistema de controle de versãopermite 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áriauma política para ordenar e integrar todas essas alterações, de modo a evitar que um desenvolvedor sobrescreva asalteraçõ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 ocompartilhamento 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ópiade 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 determinadoarquivo do projeto. Ela é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causaralguns 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 dasua cópia de trabalho. Ao final, as alterações de cada desenvolvedor são mescladas no repositório formando a versãofinal. A solução "copia-modifica-resolve" parece um pouco estranha e bagunçada a princípio, mas funciona bem naprática. Conflitos são raros e são causados basicamente pela falta de comunicação entre desenvolvedores. Na grandemaioria dos casos, as alterações não se sobrepõe e são mescladas automaticamente pelo sistema de controle deversão.

Conjunto de mudançasÉ o conjunto de todas as alterações que ocorreram no sistema para atender um determinado fim, ou num determinadoperíodo de tempo. Fazendo um mapeamento dos itens que foram mudados para uma dada versão do sistema com osmotivos 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.

Gerência de Configuração de Software 31

Gerência de mudançasA Gerência de mudanças é uma parte geralmente negligenciada da Gerência de configuração. Como ela não temresultados imediatos para os desenvolvedores e engenheiros de software envolvidos no projeto, estes acabam por nãoperceber 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. Estaatividade também pode ser parcialmente automatizada, e diversos Sistemas de controle de versão já são integradoscom sistemas de gerência de mudanças. A gerência de mudanças tem por objetivo mapear, para cada mudançaefetuada no sistema, qual foi o motivo que gerou esta mudança. É comum vermos em sistemas de software arquivosque 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• correção do problema 356• correção do problema 358• 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çõesComo o repositório registra todas as alterações que foram efetuadas, o sistema de controle de versão pode informarcom facilidade quais as alterações que foram realizadas entre uma revisão e outra, quando isso ocorreu e quem fez asalteraçõ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 doRepositó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/oudocumentação do usuário com o código. O Rational Unified Process recomenda que a verificação dessa consistênciaseja 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 emrevisar o conteúdo.

Gerência de Configuração de Software 32

Executar Auditoria de Configuração Funcional

Uma Auditoria de Configuração Funcional (FCA) confirma que uma baseline atende aos requisitos estabelecidospara 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 porprocedimentos 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 daAuditoria 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 descritoanteriormente. 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 SoftwareA finalidade da política de Gerência de Configuração de Software consiste em definir a maneira como as atividadesde Gerência de Configuração de Software serão executadas, o momento adequado, os responsáveis em executa-las eos conceitos envolvidos no processo. Entre as definições que devem contar nas políticas de Gerência de configuraçãode 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 demudanç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.

Gerência de Configuração de Software 33

• Em geral apenas a primeira auditoria de configuração de uma linha-base precisa de intervenção humana, sendoque as auditorias subseqüentes apenas verificam se houve quebra da integridade dos arquivos auditados.

PapéisUma das principais definições da política de Gerência de Configuração de Software são os papeis a seremdesempenhados. A política não determina quais pessoas desempenharão quais papeis, cabendo isso a gerência deprojeto. 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, ouno contexto do projeto, se for o caso. Em geral é uma pessoa da área de infra-estrutura com bons conhecimentosda plataforma operacional e das ferramentas usadas.

• Gestor de Configuração de Software, ou Responsável de Gerência de Configuração de Software. Ele é oresponsável por aprovar e gerenciar as atividades relativas a Gerência de Configuração de Software, coordenar aequipe de Gerência de Configuração de Software e algumas vezes, coordenar o trabalho de integração desistemas.

• Auditor de Configuração de Software. Ele é o responsável pela realização das auditorias de configuração nosprojetos.

• Desenvolvedor. Ele é o principal usuário da Gerência de configuração de software, sendo quem produz os itens deconfiguraçã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• Engenharia de software

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)

Processos de Engenharia de Software 34

Processos de Engenharia de Software

DefiniçãoUm 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 emanter os produtos de software finais requeridos.

ConceitosOs processos são divididos em atividades ou tarefas. Uma atividade é um passo de processo que produz mudanças deestado visíveis externamente no produto de software. Atividades incorporam e implementam procedimentos, regras epolí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 epode ser utilizado posteriormente como matéria prima para a mesma ou para outra atividade a fim de gerar novosprodutos.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ênciacom outras atividades, as datas de início e fim planejadas, os recursos a serem alocados e os agentes responsáveispela mesma.O agente pode ser uma pessoa ou uma ferramenta automatizada (quando a atividade é automática) e relaciona-secom as atividades de um processo. Os agentes podem estar organizados em cargos, aos quais podem ser definidasdiferentes responsabilidades.A realização do processo é afetada pelas restrições, que podem atingir atividades, agentes, recursos, artefatos, papéise seus relacionamentos. Uma restrição é uma condição definida que um passo de processo deve satisfazer antes oudepois de ser executado.

Processos de Engenharia de Software 35

Atividade de Processos de Engenharia de Software e seus inter-relacionamentos

BibliografiaReis, 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

Qualidade de Software 36

Qualidade de SoftwareA qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidadedo software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados nagarantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produtofinal 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 aum 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 dedesenvolvimento[1] , desta forma, é comum que a busca por um software de maior qualidade passe necessariamentepor 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 qualidadecomo a conformidade aos requisitos. Essa definição exige determinar dois pontos: I) o que se entende porconformidade; e II) como são especificados - e por quem - os requisitos.

Principais tópicosPara 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 paraavaliá-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 daqualidade de software.Muita coisa pode ser encontrada no site http:/ / www. ibqts. com. br O IBQTS, Instituto Brasileiro de Qualidade emTestes de Software

Qualidade de Software 37

Requisitos de qualidadeRequisitos de qualidade é um tópico por si dentro do assunto qualidade. Dentro da ótica desta última, espera-se queos requisitos sejam definidos de maneira a caracterizar completamente o produto a ser construído. Nesse aspecto - eem relação à definição de Brooks - é evidente que as zonas de sombra dentro de uma especificação abrem margem atodo 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 umproduto 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 dadosobtidos devem trazer informação que possa levar ao controle de desvios, localização de defeitos e outras ocorrênciasnegativas.

O processo de softwareNas últimas décadas foram propostas dezenas de metodologias e processos adaptados a diferentes cenários eprodutos. 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 assuntosã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 edoutorado, abordando tópicos particulares em um ou mais de tais métodos, ou propondo ainda novas adaptações acasos particulares.A situação deixa evidente que há um vácuo a ser preenchido - atacar a raiz do problema e identificar uma estruturasuficientemente geral, capaz de explicar o problema de qualidade e ser adaptada a todos os cenários diferentes. Se talobjetivo é possível resta a ser provado - assunto para novos artigos e teses.

Garantia de qualidade de softwareA Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos váriosníveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. AGQS atua como "guardiã", fornecendo um retrato do uso do Processo e não é responsável por executar testes desoftware ou inspeção em artefatos.Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandesobjetivos de um projeto de desenvolvimento de software, quais sejam, desenvolver software de alta qualidade, teralta produtividade da equipe de desenvolvimento, cumprir o cronograma estabelecido junto ao cliente e nãonecessitar de recursos adicionais não previstos.Para conseguir esses objetivos a área-chave de processo GQS estimula a atuação das equipes responsáveis pelodesenvolvimento de software em diversas frentes objetivando internalizar comportamentos e ações, podendo-sedestacar:• 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;

Qualidade de Software 38

• 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 oProcesso Serpro de Desenvolvimento de Soluções (PSDS).O PSDS foi construído por pessoas das unidades da empresa que procuraram aproveitar as melhores práticasexistentes e consagradas.O "CMM - Capability Maturity Model for Software /SEI" é uma estrutura-"framework", que descreve os principaiselementos de um processo de desenvolvimento de software efetivo. O CMM descreve os estágios de maturidadeatravés dos quais Organizações de software evoluem o seu ciclo de desenvolvimento de software através de suaavaliação contínua, identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Estecaminho 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 ganharcontrole de seu processo de desenvolvimento de software e como evoluir para uma cultura de excelência na gestãode software. O objetivo principal nas transações destes níveis de maturidade é a realização de um processocontrolado e mensurado como a fundação para melhoria contínua. Cada nível de maturidade possui um conjunto depráticas de software e gestão específicas, denominado áreas-chave do processo. Estas devem ser implantadas para aorganização atingir o nível de maturidade em qualidade de software.

Bibliografia1. 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

Qualidade de Software 39

• 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

Modelos ciclo de vidaPerceber 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 setorne visível todo o processo de desenvolvimento. O termo modelo do ciclo de vida é utilizado para descrever ummodelo que visa descrever um grupo de actividades e a forma como elas se relacionam. Os modelos maissofisticados incluem ainda uma descrição de quando e como se deve mover de uma actividade para a próxima e osdeliverables que devem ser produzidos em cada etapa. A razão pela qual estes modelos são tão conhecidos é o factoajudarem as equipas de desenvolvimento, e em particular os gestores, a obter uma visão geral do projecto de forma aser possível segui-lo passo a passo, saber que deliverables foram especificados, o alocamento de recursos e osobjectivos propostos. Estes "modelos de ciclo de vida" ou "modelos de processos" são tipicamente produzidos apartir de uma perspectiva de que poderão existir vários modelos para o mesmo processo. Nenhum modelo é capaz dedar uma visão completa de um determinado processo.

Modelos de ProcessosEmbora este artigo seja mais focado aos modelos de ciclo de vida na engenharia de requisitos de projetos desoftware, é importante ter uma ideia dos vários tipos de modelos de processos existentes. Os tipos de modelos deprocessos que podem ser produzidos dependem do uso que lhes será dado. Poderá ser necessário um modelo paraexplicar como está organizada a informação de processos, um modelo que ajude a compreender e permita melhorarprocessos, um modelo para satisfazer certos requisitos de qualidade, etc. Alguns exemplos de modelos quedescrevem processos são:

Modelo de atividades.

Modelos de Atividade

A figura seguinte é um exemplo deste tipo de modelo. Estesmodelos mostram os principais processos e atividades deengenharia de requisitos e o seu sequenciamento (aproximado).Este tipo de modelos não permite forçar um processo mas dá umavisão geral do mesmo e são tipicamente construídos como pontode partida para a descrição de um processo com secções separadasdando cobertura a cada caixa no modelo. Os modelos descrevem ocontexto das diferentes atividades de um processo, mostrando outros processos que consomem ou produzem input deum outro.

Modelos ciclo de vida 40

Modelos de Atividade de Granularidade FinaEstes são modelos mais detalhados para um processo específico. Podem ser utilizados para perceber e melhorarprocessos existentes.

Modelos Papel-AçãoEstes 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çãoEstes modelos mostram as entradas, saídas e resultados intermédios dos processos e relações entre eles. Podem serutilizados num sistema de gestão de qualidade e como modelos complementares das actividades de processo.

Atividades do Processo de Engenharia de RequisitosDiferentes tipos de organizações abordam a engenharia de requisitos de formas radicalmente diferentes. Umacompanhia aeroespacial que se encontre a especificar sistemas de software e hardware muito complexos não utiliza omesmo processo de engenharia de requisitos que uma outra companhia que desenvolve produtos de consumo paracomputadores pessoais. No entanto, as diferenças entre estes processos encontram-se geralmente no nível de detalhedos processos. Num nível abstracto, todos os processos de engenharia de requisitos podem ser descritos pelo modelomostrado na figura anterior. Antes de apresentar os modelos de ciclo de vida para o processo de engenharia derequisitos, torna-se necessário compreender melhor as actividades nele envolvidas. As actividades do processo deengenharia de requisitos são as seguintes:

Levantamento de RequisitosOs requisitos do sistema são obtidos através de consultas aos stakeholders, documentação do sistema, conhecimentodo domínio e estudos de mercado. Este processo é também conhecido como aquisição de requisitos ou descoberta derequisitos.

Análise e Negociação de RequisitosOs requisitos são analisados em detalhe e os diferentes stakeholders negociam para decidirem que requisitos serãoaceitos. Este processo é necessário visto que é inevitável o aparecimento de conflitos entre requisitos de diferentesfontes, existência de informação incompleta ou então os requisitos podem ser incompatíveis com o orçamentodisponível para o desenvolvimento do sistema. Existe, no entanto, alguma flexibilidade no negociamento derequisitos para que seja possível concordar acerca de conjunto de requisitos para o sistema.

Documentação de RequisitosOs 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 osstakeholders. Isto significa que os requisitos devem ser detalhados utilizando linguagem natural e diagramas. Podemtambém ser produzidos documentos de sistema mais detalhados tais como modelos de sistema.

Validação de RequisitosTodos os requisitos obtidos nas actividades anteriores devem ser cuidadosamente verificados para apurar se estãocompletos e são consistentes. Este processo tem como finalidade detectar potenciais problemas no documento deespecificação de requisitos antes que este seja utilizado como base para o desenvolvimento do sistema.

Modelos ciclo de vida 41

Modelos de Ciclo de VidaOs modelos existentes possuem diferentes graus de sofisticação e complexidade. Para projetos que envolvem umaequipe de desenvolvimento pouco numerosa e experiente, o mais adequado será provavelmente um processosimples. No entanto, para sistemas maiores que envolvem equipes de dezenas ou centenas de elementos e milharesde 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. É importantefazer notar que isto não significa que se perca em inovação ou que se põe entraves à criatividade. Significa apenasque é 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ãosimplificada da realidade. É suposto ser uma abstracção e, tal como todas as boas abstracções, apenas a quantidadede detalhe necessária ao trabalho em mãos deve ser incluída. Qualquer organização que deseje por um modelo deciclo de vida em prática irá necessitar de adicionar detalhes específicos para dadas circunstâncias e diferentesculturas. Por exemplo, a Microsoft quis manter uma cultura de pequena equipa e ao mesmo tempo tornar possível odesenvolvimento 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 termosde engenharia de requisitos para projectos de software. Dependendo do tipo de sistema em desenvolvimento podenão ser completamente possível ou até apropriado seguir os modelos rigorosamente. É de notar também que para porem prática um destes modelos e aplica-lo a um projecto real seria necessário adicionar mais detalhe.

Modelos em Engenharia de Software e RequisitosA 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 haviaconcordância em termos dos métodos a levar a cabo no desenvolvimento de software. Desde então ao longo dos anosmuitos modelos têm sido propostos refletindo assim a grande variedade de interpretações e caminhos que podem sertomadas 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 segundoporque mostram como a ênfase no desenvolvimento de software mudou gradualmente de forma a incluir uma visãomais interativa e centrada no utilizador.

Modelo em Cascata

Modelo em Cascata.

O modelo de ciclo de vida em cascata foi oprimeiro modelo a ser conhecido emengenharia de software e está na base demuitos ciclos de vida utilizados hoje em dia.Este consiste basicamente num modelolinear em que cada passo deve sercompletado antes que o próximo passopossa ser iniciado. Por exemplo, a análise derequisitos deve ser completada antes que odesenho do sistema possa ser iniciado. Osnomes dados a cada passo variam, assim como varia a definição exata de cada um deles, mas basicamente o ciclo devida 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

Modelos ciclo de vida 42

completados. Foi então reconhecido que seria necessário dar feedback às atividades iniciais a partir do momento emque este modelo começou a ser usado em grande escala. A ideia de interacção não foi incorporada na filosofia domodelo de cascata. Neste momento, é incluído algum nível de interação na maior parte das versões deste modelo esão comuns sessões de revisão entre os elementos responsáveis pelo desenvolvimento do sistema. No entanto, apossibilidade de revisão e avaliação com os utilizadores do sistema não está contemplada neste modelo.

Modelo em EspiralDurante muitos anos, o modelo cascata foi a base da maior parte do desenvolvimento de projetos de software, masem 1988 Barry Boehm sugeriu o modelo em espiral. Do modelo em espiral para desenvolvimento de software saltama vista dois aspectos: a análise de risco e prototipagem. O modelo espiral incorpora-os de uma forma interativapermitindo que as ideias e o progresso sejam verificados e avaliados constantemente. Cada interação à volta daespiral pode ser baseada num modelo diferente e pode ter diferentes atividades. No caso da espiral, não foi anecessidade do envolvimento dos utilizadores que inspirou a introdução de interação mas sim a necessidade deidentificar e controlar riscos. No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividadessão repetidas até uma decisão ser tomada e o documento de especificação de requisitos ser aceito. Se foremencontrados 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 ModelosNa tabela seguinte estão sumariadas algumas vantagens e desvantagens de vários modelos de ciclo de vida utilizadosem 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 quenã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 astarefas de maior risco sejam levadas com o mínimo de custos.Cada iteração da espiral pode ser customizada para as necessidadesespecíficas de cada projecto.

É complexo e requer atenção e conhecimentoespeciais para o levar a cabo.

PrototipagemEvolucioná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 tempoque o projecto vai demorar.Não há forma de saber o número de iterações queserão necessárias.

Codificação eCorrecção

Não há tempo gasto em planejamento, documentação, gestão dequalidade e cumprimento de standards.Requer pouca experiência.

Perigoso.Não há forma de assegurar qualidade e identificarriscos.Falhas fundamentais não percebidasimediatamente resultando em trabalho deitadofora.

Entre outros modelos utilizados estão: Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Toolse Off-the-Shelf.

Modelos ciclo de vida 43

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 Estruturada1. REDIRECIONAMENTO Análise estruturada

Projeto EstruturadoProjeto estruturado é a atividade da especificação das atividades que compõem um modelo funcional detransformação das necessidades do usuário. São provenientes das fases de análise e diagramação e de plano deimplementação.

Programação Estruturada 44

Programação EstruturadaProgramação estruturada é uma forma de programação de computadores que preconiza que todos os programaspossí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 programadorespara a criação de estruturas simples em seus programas, usando as subrotinas e as funções. Foi a forma dominante nacriaçã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 estruturadaainda é muito influente, uma vez que grande parte das pessoas ainda aprendem programação através dela. Alémdisso, 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 oCobol ainda utilizam o paradigma estruturado (muito embora possuam suporte para a orientação à objetos).

Análise EssencialA Análise Essencial propõe o particionamento do sistema por eventos. A rigor, o valor de um sistema está na suacapacidade de responder com eficácia a todos os estímulos a que for submetido. Assim, um sistema é construído pararesponder a estímulos. A cada estímulo, o sistema deve reagir produzindo uma resposta predeterminada. A expressãoEssential Analysis, traduzida por Análise Essencial, foi proposta em 1984 por McMenamim e Palmer para refletir aintrodução dos novos conceitos que estavam sendo incorporados à Análise Estruturada clássica.

ConceitoA 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 ossistemas 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.

Análise Essencial 45

Modelo EssencialApresenta o sistema num nível de abstração completamente independente de restrições tecnológicas. Antes que umsistema seja implementado, é necessário conhecer-se a sua verdadeira essência, não importando saber se suaimplementação vai ser manual ou automatizada, e nem mesmo que tipo de hardware ou software vai ser usado. OModelo 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 oambiente;Métodos Envolvidos:Modelagem de Dados e Modelagem Funcional.

Modelo AmbientalO 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. Declaração de Objetivos2. Diagrama de Contexto3. Lista de Eventos4. 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 comos quais o sistema se comunica (Entidades Externas), os dados que o sistema recebe do mundo exterior e que dealguma forma devem ser processados, os dados produzidos pelo sistema e enviados ao mundo exterior e afronteira entre o sistema e o resto do mundo.

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 algumaresposta. É um ativador de uma função. É a forma como o evento age sobre o sistema. É a conseqüência do fato deter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz com que osistema 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 dofato de ter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz comque 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 oresultado da execução de alguma função interna no sistema como conseqüência do reconhecimento pelo sistema deque um evento ocorreu.

Modelo ComportamentalDefine o comportamento interno que o sistema deve ter para se relacionar adequadamente com o ambiente.Ou, oModelo Comportamental é definido do ponto de vista interno, é o modelo interior do sistema. Descreve de quemaneira o sistema, enquanto um conjunto de elementos inter-relacionados, reage, internamente, como um todoorganizado, 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 47

Modelo de ImplementaçãoTem como objetivo definir a forma de implementação do sistema em um ambiente técnico específico. Apresenta osistema num nível de abstração completamente dependente de restrições tecnológicas.

SimbologiaConjunto 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.

SADT 48

SADT

Structured Analysis and Design TechniqueStructured Analysis and Design Technique — SADT é uma técnica para apresentação de idéias. Esta técnica foiproposta por Douglas T. Ross em 1977, no artigo Ross, D. (1977) “Structured Analysis (AS): A Language forCommunicating 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 pontode vista.

Serviço de Apoio à Diagnose e Terapia – SADTServiço de Apoio à Diagnose e Terapia, ou Serviço Auxiliar de Diagnóstico e Terapia (SADT) é uma modalidade deprestação de serviços na área da saúde que se utiliza de recursos de uma fonte financiadora (SUS, Particular, ouConvênio) com o objetivo de esclarecer o diagnóstico ou realizar procedimentos terapêuticos específicos parapacientes externos, internos ou de emergência de um serviço de saúde. Geralmente organiza-se por um sistemainformatizado que registra a oferta dos serviços em determinadas especialidades, sejam eles próprios, terceirizadosou contratados interna ou externamente ao estabelecimento de saúde.

DFDO DFD ou Diagrama de Fluxos de Dados é uma ferramenta para a modelagem de sistemas. Ela fornece apenasuma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Se estivermos desenvolvendo umsistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menosimportâ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 processosfuncionais, 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 DadosO DFD pode ter vários níveis de detalhamento de acordo com anecessidade 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 processonã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çãográ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 sendoformado por uma representação gráfica (uma rede de funções ou processos interligados), acompanhada da descriçãode cada função e suas interfaces. A representação gráfica do modelo funcional costuma ser expressa através de umdiagrama 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 caixafaz 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 Relacionamentos1. REDIRECIONAMENTO Modelo de entidades e relacionamentos

Orientação a Objetos

Orientação aobjetos

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 nacomposição e interação entre diversas unidades de software chamadas de objetos.

Orientação a Objetos 50

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 deinteligência artificial e da linguística, no campo da abstração de conceitos do mundo real. Na qualidade de método demodelagem, é tida como a melhor estratégia para se eliminar o "gap semântico", dificuldade recorrente no processode modelar o mundo real do domínio do problema em um conjunto de componentes de software que seja o mais fielna 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 umsistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entreestes objetos.Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes nosistema 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 deprogramaçã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ãoexemplos 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 declasse: 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 amensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos daclasse 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. Oconjunto 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 habilidadepara latir, implementada através do método deUmLatido. Um método em uma classe é apenas uma definição. Aação só ocorre quando o método é invocado através do objeto, no caso Bidu. Dentro do programa, a utilização deum método deve afetar apenas um objeto em particular; Todos os cachorros podem latir, mas você quer queapenas Bidu dê o latido. Normalmente, uma classe possui diversos métodos, que no caso da classe Cachorropoderiam ser sente, coma e morda.

• Mensagem é uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descritopor sua classe. Também pode ser direcionada diretamente a uma classe (através de uma invocação a um métodoestá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 deherança: Mamífero é super-classe de Humano. Ou seja, um Humano é um mamífero. Há herança múltipla quandouma sub-classe possui mais de uma super-classe. Essa relação é normalmente chamada de relação "é um".

Orientação a Objetos 51

• Associação é o mecanismo pelo qual um objeto utiliza os recursos de outro. Pode tratar-se de uma associaçãosimples "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 é utilizadoamplamente para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamenteapenas os métodos que alteram estes estados. Exemplo: você não precisa conhecer os detalhes dos circuitos de umtelefone para utilizá-lo. A carcaça do telefone encapsula esses detalhes, provendo a você uma interface maisamigá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ísticasmenos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidadesexistentes no domínio do sistema de software.

• Polimorfismo consiste em quatro propriedades que a linguagem pode ter (atente para o fato de que nem todalinguagem 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 emJava: "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

Orientação a Objetos 52

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)

Rational Unified ProcessO RUP, abreviação de Rational Unified Process (ou Processo Unificado Racional), é um processo proprietário deEngenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nomeIRUP 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 deaumentar 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çãoUML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadascomercialmente.É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandesprojetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquerescala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas eresponsabilidades 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 pordiversas 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 osMétodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

Linhas mestrasO RUP define as seguintes linhas-mestras e esqueletos (templates) para os membros da equipe de um ciclo deprodução: parte do cliente, e uma avaliação do progresso do projeto pela sua gerência. Além disso, ajuda osprogramadores a manterem-se concentrados no projeto.

Gestão de requisitosUma documentação apropriada é essencial para qualquer grande projeto; note que o RUP descreve como documentara 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êmsido considerados muito mais eficazes na captura de requisitos funcionais.

Rational Unified Process 53

Uso de arquitetura baseada em componentesA arquitetura baseada em componentes cria um sistema que pode ser facilmente extensível, promovendo areutilização de software e um entendimento intuitivo. Um componente normalmente se relaciona com um objeto naprogramação orientada a objetos.O RUP oferece uma forma sistemática para construir este tipo de sistema, focando-se em produzir uma arquiteturaexecutá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 deComponentes de Objectos).

Uso de software de modelos visuaisAo abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegueuma 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 ummelhor 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 utilizadapelo RUP.

Verificação da qualidade do softwareNã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 deuma 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 eenvolvendo todos os membros da equipe de desenvolvimento.

Gestão e Controle de Mudanças do SoftwareEm todos os projetos de software a existência de mudanças é inevitável. O RUP define métodos para controlar emonitorar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisíveis, ocontrole 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 noutrosistema não afetarão o seu sistema.

FasesAté 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, oRUP divide o projeto em quatro fases diferentes:1. Concepção: ênfase no escopo do sistema;2. Elaboração: ênfase na arquitetura;3. Construção: ênfase no desenvolvimento;4. Transição: ênfase na implantação.O RUP também se baseia nos 4 Ps:1. Pessoas2. Projeto3. Produto4. Processo

Rational Unified Process 54

As fases são compostas de iterações. As iterações são janelas de tempo; as iterações possuem prazo definidoenquanto 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 permitirmelhor acompanhamento.

Fase de concepçãoA fase de concepção contém os workflows [2] necessários para que as partes interessadas (stakeholders) concordemcom 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 quantidadee objetivos.

Fase de ElaboraçãoA fase de elaboração será apenas para o projeto do sistema, buscando complementar o levantamento / documentaçãodos casos de uso, voltado para a arquitetura do sistema, revisa a modelagem do negócio para os projetos e inicia aversão do manual do usuário. Deve-se aceitar: Visão geral do produto (incremento + integração) está estável?; Oplano do projeto é confiável?; Custos são admissíveis?

Fase de ConstruçãoNa 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çãoNesta 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çãodo 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 desistemas de informação saibam como as aplicações em desenvolvimento se inserem na organização. As empresasinvestem em TI, quando entendem a vantagem competitiva do valor acrescentado pela tecnologia. O objetivo demodelagem de negócios é, primeiramente, estabelecer uma melhor compreensão e canal de comunicação entreengenharia de negócios e engenharia de software. Compreender o negócio significa que os engenheiros de softwaredevem compreender a estrutura e a dinâmica da empresa alvo (o cliente), os atuais problemas na organização epossí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 ecomo usar esta visão como uma base para descrever o processo, papéis e responsabilidades.

Rational Unified Process 55

Disciplina de Requisitos

Esta disciplina explica como levantar pedidos das partes interessadas ("stakeholders") e transformá-los em umconjunto de requisitos que os produtos funcionam no âmbito do sistema a ser construído e fornecem requisitosdetalhados 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 funcionaisResultados de projeto em um modelo de análise e projeto tem, opcionalmente, um modelo de análise. O modelo dedesign serve como uma abstração do código-fonte, isto é, o projeto atua como um modelo de "gabarito" de como ocódigo-fonte é estruturado e escrito. O modelo de projeto consiste em classes de design estruturado em pacotes esubsistemas com interfaces bem definidas, representando o que irá se tornar componentes da aplicação. Ele tambémconté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ávelSistemas são realizados através da aplicação de componentes. O processo descreve como a reutilização decomponentes existentes ou implementar novos componentes com responsabilidades bem definidas, tornando osistema 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 fechadosO Rational Unified Process propõe uma abordagem iterativa, o que significa que deve-se testar todo o projeto. Istopermite encontrar defeitos tão cedo quanto possível, o que reduz radicalmente o custo de reparar o defeito. Os testessã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ê passarpelo 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 seususuários finais. Ele cobre uma vasta gama de atividades, incluindo a produção de releases externos do software, aembalagem do software e aplicativos de negócios, distribuição do software, instalação do software e prestação deajuda e assistência aos usuários. Embora as atividades de implantação estão principalmente centradas em torno dafase de transição, muitas das atividades devem ser incluídas nas fases anteriores para se preparar para a implantação,

Rational Unified Process 56

no final da fase de construção. Os processos ("workflows") de "Implantação e Ambiente" do RUP contêm menosdetalhes 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 atividadesnecessá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 asferramentas - que darão suporte à equipe de desenvolvimento. Se os usuários do RUP não entendem que o RUP é umframework de processo, eles podem percebê-lo como um processo pesado e caro. No entanto, um conceito-chavedentro do RUP foi que o processo RUP pode e, muitas vezes, deve ser refinado. Este foi inicialmente feitomanualmente, ou seja, por escrito, um documento de "caso de desenvolvimento" que especificou o processo refinadopara ser utilizado. Posteriormente, o produto IBM Rational Method Composer foi criado para ajudar a tornar estaetapa mais simples, engenheiros de processos e gerentes de projeto poderiam mais facilmente personalizar o RUPpara suas necessidades de projeto. Muitas das variações posteriores do RUP, incluindo OpenUP/Basic, a versãoopen-source e leve do RUP, são agora apresentados como processos distintos, por direito próprio, e atendem adiferentes 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 doprojeto 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: deconfiguraçã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 devemser visíveis. Ele também mantém o controle de dependências entre artefatos para que todos os artigosrelacionados sejam atualizados quando são feitas alterações

• Gerenciamento de solicitações de mudança: Durante o processo de desenvolvimento de sistemas com muitosartefatos 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 ecompleto. A solicitação de mudança também tem atributos como a causa raiz, ou a natureza (como o defeito evalorização), prioridade, etc. Esses estados e atributos são armazenados no banco de dados para produzirrelatórios úteis sobre o andamento do projeto. A Rational também tem um produto para manter a solicitações demudanç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 quedescreve 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 desenvolvimentoiterativo: 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 tentacobrir 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

Rational Unified Process 57

Princípios e melhores práticasRUP é baseado em um conjunto de princípios de desenvolvimento de software [3] e melhores práticas, por exemplo:1. Desenvolvimento de software iterativo2. Gerenciamento de requisitos3. Uso de arquitetura baseada em componente4. Modelagem visual de software5. Verificação da qualidade do software6. Controle de alteração no software

Desenvolvimento iterativoDado o tempo gasto para desenvolver um software grande e sofisticado, não é possível definir o problema e construiro software em um único passo. Os requerimentos irão freqüentemente mudar no decorrer do desenvolvimento doprojeto, devido a restrições de arquitetura, necessidades do usuário ou a uma maior compreensão do problemaoriginal. Alterações permitem ao projeto ser constantemente refinado, além de assinalarem itens de alto risco doprojeto como as tarefas de maior prioridade. De forma ideal, ao término de cada iteração haverá uma versãoexecutável, o que ajuda a reduzir o risco de configuração do projeto, permitindo maior retorno do usuário e ajudandoao 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 repetitivoUsando iterações, um projeto terá um plano geral, como também múltiplos planos de iteração. O envolvimento dosstakeholders é freqüentemente encorajado a cada entrega. Desta maneira, as entregas servem como uma forma de seobter o comprometimento dos envolvidos, promovendo também uma constante comparação entre os requisitos e odesenvolvimento da organização para as pendências que surgem.

Gerenciamento de requisitosO Gerenciamento de requisitos no RUP está concentrado em encontrar as necessidades do usuário final pelaidentificação e especificação do que ele necessita e identificando aquilo que deve ser mudado. Isto traz comobenefí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

Rational Unified Process 58

• Gerenciar o escopo do sistema trata das modificações de escopo que serão comunicadas baseadas nos resultadosdo 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 deforma a criar uma especificação de requerimentos de software que pode servir como um contrato entre o seugrupo 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 derequerimento num projeto que já começou

Uso de arquitetura baseada em componentesArquitetura baseada em componentes cria um sistema que é facilmente extensível, intuitivo e de fácil compreensão epromove a reusabilidade de software. Um componente freqüentemente se relaciona com um conjunto de objetos naprogramação orientada ao objeto.Arquitetura de software aumenta de importância quando um sistema se torna maior e mais complexo. RUP foca naprodução da arquitetura básica nas primeiras iterações. Esta arquitetura então se torna um protótipo nos ciclosiniciais de desenvolvimento. A arquitetura desenvolve-se em cada iteração para se tornar a arquitetura final dosistema. RUP também propõe regras de projeto e restrições para capturar regras de arquitetura. Pelodesenvolvimento 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 comoCORBA e COM, ou JavaEE, ou PHP

Modelagem visual de softwareAbstraindo sua programação do seu código e representando-a usando blocos de construção gráfica constitui-se deuma forma efetiva de obter uma visão geral de uma solução. Usando esta representação, recursos técnicos podemdeterminar a melhor forma para implementar a dado conjunto de interdependências lógicas. Isto também constróiuma 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. RUPespecifica 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 eoutros objetos. RUP também discute outras formas para construir estes modelos.

Verificar qualidade de softwareGarantia 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 ajudano planejamento do controle da qualidade e cuida da sua construção em todo processo, envolvendo todos osmembros da equipe. Nenhuma tarefa é especificamente direcionada para a qualidade; o RUP assume que cadamembro da equipe é responsável pela qualidade durante todo o processo. O processo foca na descoberta do nível dequalidade esperado e provê testes nos processos para medir este nível.

Rational Unified Process 59

Controle de alterações no softwareEm todos os projetos de software, mudanças são inevitáveis. RUP define métodos para controlar, rastrear emonitorar 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. Esteconceito é 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] http:/ / www. synstec. com. br/ synsweb/ components/ images/ imgRup. gif[2] http:/ / pt. wikipedia. org/ wiki/ Fluxo_de_trabalho[3] http:/ / www-128. ibm. com/ developerworks/ rational/ library/ oct05/ kroll/[4] http:/ / www. ibm. com/ br/ shop/ trainings/[5] http:/ / www. wthreex. com/ rup/[6] http:/ / www. ibm. com/ software/ br/ rational/[7] ftp:/ / public. dhe. ibm. com/ / software/ pdf/ br/ RUP_DS. pdf[8] http:/ / www. javafree. org/ content/ view. jf?idContent=7

Scrum 60

Scrum

O processo Scrum.

O Scrum é um processo dedesenvolvimento iterativo eincremental para gerenciamento deprojetos e desenvolvimento ágil desoftware. Apesar de a palavra não serum acrônimo, algumas empresas queimplementam o processo a soletramcom letras maiúsculas como SCRUM.Isto pode ser devido aos primeirosartigos de Ken Schwaber, quecapitalizava SCRUM no título.

Apesar de Scrum ter sido destinadopara gerenciamento de projetos de software, ele pode ser utilizado em equipes de manutenção de software ou comouma abordagem geral de gerenciamento de projetos/programas.

HistóriaInicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação deautomó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 emultidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamenteeficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, JohnScumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, naempresa 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 softwaresem 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. Eletem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias dedesenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoasnecessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisacientí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 serusado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum deScrums.

Scrum 61

CaracterísticasScrum é 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ócio3. 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 equipessão auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outrafunção extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamenteas 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 daequipe 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 serresolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagemempírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização dahabilidade 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 deprojetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingirqualidade 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 é mantidopelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Owner pode altera-lo a aqualquer momento, desde que os itens alterados não estejam na sprint. O Sprint backlog é uma interpretação doProduct backlog e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar algunsdos itens principais no Product backlog. O Product backlog e o sprint backlog são, então, duas coisas totalmentediferentes, 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

Scrum 62

então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum simplificadoMuitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, aadaptabilidade 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áriasUm momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estasdiscussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a umquadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa horapermite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentesestão focadas no trabalho e não em questões pessoais.

Scrum SoloScrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há umagrande 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 desprint, 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 63

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

Programação extrema 64

Programação extremaProgramação extrema (do inglês eXtreme Programming), ou simplesmente XP, é uma metodologia ágil paraequipes 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 desenvolvimentode software.Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback e coragem. A partirdesses 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 oucanceladas.A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganho de curto prazo naprodutividade, 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áticasPara 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 fortesde 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 deJogo 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. Comoo escopo é reavaliado semanalmente, o projeto é regido por um contrato de escopo negociável, que diferesignificativamente das formas tradicionais de contratação de projetos de software. Ao final de cada semana, ocliente 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 noprocesso de aceitação por parte do cliente, que já pode testar uma parte do sistema que está comprando. Asversões chegam a ser ainda menores que as produzidas por outras metodologias incrementais, como o RUP.

Programação extrema 65

• Metáfora (Metaphor): Procura facilitar a comunicação com o cliente, entendendo a realidade dele. O conceito derápido para um cliente de um sistema jurídico é diferente para um programador experiente em controlarcomunicação em sistemas em tempo real, como controle de tráfego aéreo. É preciso traduzir as palavras do clientepara o significado que ele espera dentro do projeto.

• Projeto Simples (Simple Design): Simplicidade é um princípio da XP. Projeto simples significa dizer que caso ocliente tenha pedido que na primeira versão apenas o usuário "teste" possa entrar no sistema com a senha "123" eassim 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 é aconfusão por parte dos programadores de código simples e código fácil. Nem sempre o código mais fácil de serdesenvolvido levará a solução mais simples por parte de projeto. Esse entendimento é fundamental para o bomandamento 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 dedesenvolvimento.

• 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 (40horas/semana, 8 horas/dia), sem horas extras. Horas extras são permitidas quando trouxerem produtividade para aexecução do projeto. Outra prática que se verifica neste processo é a prática de trabalho energizado, onde se buscatrabalho motivado sempre. Para isto o ambiente de trabalho e a motivação da equipe devem estar sempre emharmonia.

• Reuniões em pé (Stand-up Meeting): Reuniões em pé para não se perder o foco nos assuntos, produzindoreuniõ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 parapoder 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 acompanhaajudando a desenvolver suas habilidades. Desta forma o programa sempre é revisto por duas pessoas, evitando ediminuindo assim a possibilidade de defeitos. Com isto busca-se sempre a evolução da equipe, melhorando aqualidade do código fonte gerado.

• Padrões de Codificação (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras paraprogramar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pelamesma 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) edepois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra oprocesso de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade doprojeto seja mantida.

• Refatoração (Refactoring): É um processo que permite a melhoria continua da programação, com o mínimo deintroduçã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 decódigo-fonte;

• Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperaruma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidadede erros no código fonte. Integrar de forma contínua permite saber o status real da programação.

Programação extrema 66

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] http:/ / www. improveit. com. br/ xp/ livroxp[2] http:/ / www. javafree. org/ content/ view. jf?idContent=5[3] http:/ / www. javafree. org/ content/ view. jf?idContent=16[4] http:/ / www. extremeprogramming. org[5] http:/ / xp-rs. blogspot. com[6] http:/ / www. improveit. com. br/ xp[7] http:/ / xprio. blogspot. com[8] http:/ / www. ime. usp. br/ ~xp[9] http:/ / www. agilcoop. org. br/ agilcast

Microsoft Solution Framework 67

Microsoft Solution FrameworkA MSF foi criado em 1994, e originou-se da análise de times de projetos e grupo de produtos, estas análises eramconstatadas com a indústria de práticas e métodos. Estes resultados combinados eram consolidados em melhorespraticas entre pessoas e processos.O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimentode soluções de software dentro da Microsoft e também para os milhares de clientes e parceiros da Microsoft em todoo mundo.A disseminação deste método, agora na versão 4.0 no Visual Studio 2005, normalmente induz as pessoas acompará-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 paraprojetos de desenvolvimento de softwares.Um projeto MSF é regido por ciclos ou iterações. A cada ciclo, cada componente da equipe executa suas funções eatualiza o resultado do seu trabalho conforme a necessidade. Os ciclos se repetem até que o projeto seja concluído oucada versão seja lançada.Cada componente da equipe será responsável por um ou mais papéis, dependendo do tamanho ou da complexidadedo 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 seaprofunda 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 umaabordagem simples e direta das técnicas apresentadas. Ou seja, o MSF permite uma fácil compreensão tanto porparte 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

Microsoft Solution Framework 68

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ÇÃONo início de um projeto da solução, antes da fase de visão/escopo, a organização precisa ter um claro entendimentodestes 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

Microsoft Solution Framework 69

precisam de uma padronizado, repetitivo e mais ambiente controlado. Para atender estas necessidades, a Microsoftrepresenta o metamodelo de 4,0 MSF em dois modelos que prevêem prescritivo metodologia específica processo deorientação, chamado Microsoft Solutions Framework para Agile Software Development (MSF4ASD) e MicrosoftSolutions Framework para Capability Maturity Model Integration Melhoria de Processos (MSF4CMMI). Note-seque estes processos de engenharia de software podem ser modificados e personalizados de acordo com aspreferê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 eambientes para todos os tipos de projetos. MSF, portanto, suporta múltiplas abordagens processo, para que possa seradaptado para apoiar qualquer projecto, independentemente da sua dimensão ou complexidade. Esta flexibilidadesignifica que ele pode oferecer suporte a uma ampla variação no grau de execução dos processos de engenharia desoftware, 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 aoprogressivo 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ãode assegurar um fluxo de valor do projecto. Cada iteração tem um foco diferente eo resultado é uma porção estáveldo sistema global.Seguem-se os oito princípios fundamentais, que constituem a espinha dorsal para os outros modelos e disciplinas doMSF:1. comunicação aberta2. Trabalhar em prol de uma visão compartilhada3. Capacitar os membros da equipa4. Estabelecer uma responsabilidade clara e partilhada5. Concentre-se em negócio prestação valor6. Fique ágil, esperam mudanças7. Invista na qualidade8. Aprenda com todas as experiênciasMSF ModelsMSF consiste de dois modelos:1. MSF equipe modelo. Este artigo descreve o papel dos vários membros da equipe de projeto de desenvolvimentode 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 aresponsabilidades, 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 deGovernança MSF tem cinco faixas sobreposição de actividade (ver abaixo), cada um com uma meta de qualidade

Microsoft Solution Framework 70

definidos. Essas faixas de atividade definir o que precisa ser cumprida e deixar como eles se realizem para a equipaseleccionada metodologia. Por exemplo, as faixas podem ser pequenos e realizada no âmbito rapidamente para sercoerente com uma metodologia Agile, ou pode ser serializada e alongada para ser coerente com uma metodologiaCachoeira.• 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çãoMSF 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ãoMSF para Agile Software Development metodologiaO 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 MSF4ASDprevê um processo de orientação que incide sobre as pessoas e as mudanças. Inclui aprendizagem de oportunidades ede avaliações usando iterações em cada iteração.MSF para Capability Maturity Model Integration metodologia Melhoria de ProcessosO 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 deformalidade e cerimônia.O MSF4 CMMI é uma metodologia formal para a engenharia de software. Capability Maturity Model foi criada apartir do Software Engineering Institute da Universidade Carnegie Mellon, e é um processo de melhoria abordagemque fornece às organizações com os elementos essenciais do processo de melhoria contínua, resultando em umaredução SDLC, a melhoria da capacidade de cumprir as metas custo e cronograma, materiais de construção de altaqualidade. 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 conformidadesconfiando unicamente na confiança e na capacidade de cada um dos membros da equipe. O MSF4CMMI tem maisdocumentos obrigatórios e relatórios do que a versão ágil, mais formal e desenvolvimento deste processo reduz riscoem grandes projetos de software e fornece um estatuto mensuráveis. Uma das vantagens de utilizar o CMMI é oprocesso pelo qual uma avaliação padrão poderão comparar a capacidade de desenvolver software em outrasorganizações.

Diagrama de contexto 71

Diagrama de contextoO DFD de mais alto nível que representa todo o sistema como um único processo é conhecido como diagrama decontexto, e é composto por fluxos de dados que mostram as interfaces entre o sistema e as entidades externas. Odiagrama é 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 osrelacionamentos com outros processos e elementos externos à empresa (ex.: clientes, fornecedores)e mostra ascaracteristicas 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.

Diagrama de fluxos de dadosO DFD ou Diagrama de Fluxos de Dados é uma ferramenta para a modelagem de sistemas. Ela fornece apenasuma visão do sistema, a visão estruturada das funções, ou seja, o fluxo dos dados. Se estivermos desenvolvendo umsistema no qual os relacionamentos entre os dados sejam mais importantes que as funções, podemos dar menosimportâ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 processosfuncionais, 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 DadosO DFD pode ter vários níveis de detalhamento de acordo com anecessidade do sistema. O Diagrama de Contexto é uma representaçãomacro do sistema. Em seguida, temos os DFDs de níveis. O nível maisalto é conhecido como DFD de nível 0 e está logo abaixo do diagrama de contexto. Neste nível as principais funçõesdo 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çãográ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

Diagrama de fluxos de dados 72

de cada função e suas interfaces. A representação gráfica do modelo funcional costuma ser expressa através de umdiagrama 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 caixafaz 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 relacionamentoDiagrama entidade relacionamento é um modelo diagramático que descreve o modelo de dados de um sistemacom alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. É usadopara 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çõesOs 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 pordiversos campos-chave de outras tabelas. A relação então se reduz para uma relação 1..n, sendo que o lado nficará 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

Dicionário de dados 73

Dicionário de dadosUm dicionário de dados (do inglês data dictionary) é uma coleção de metadados que contêm definições erepresentações de elementos de dados.Dentro do contexto de SGBD, um dicionário de dados é um grupo de tabelas, habilitadas apenas para leitura ouconsulta, 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çoUm dos benefícios de um dicionário de dados bem preparado é a consistência entre itens de dados através dediferentes tabelas. Por exemplo, diversas tabelas podem conter números de telefones; utilizando uma definição deum dicionário de dados bem feito, o formato do campo 'número de telefone' definido com "( )9999-9999" deverá serobedecido 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 depadronizar precisamente definições semânticas a serem adotadas na empresa toda; portanto, ele deve incluir tantodefinições semânticas como de representação para elementos de dados, sendo que os componentes semânticos focamna criação precisa do significado dos elementos de dados, e de outro lado, as definições de representação indicamcomo os elementos de dados são armazenados em uma estrutura de computador de acordo com seu tipo, ou seja, sesão dados do tipo inteiro, caracter ou formato de data (veja Tipos de Dados). Os dicionários de dados são maisprecisos 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 desseselementos de dados.Os dicionários de dados são gerados, normalmente, separados do Modelo de Dados visto que estes últimoscostumam incluir complexos relacionamentos entre elementos de dados.

Notação

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 [].

</pre>

Tabela de decisão 74

Tabela de decisãoA 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 tabelade 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 oucargo 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 respostaspossíveis de cada condição.Ex.Condição 1 sim/não:     =2Condição 2 sim/não:     =2Condição 3 Sim/não:     =2 xQuantidade de Regras:   =8

Árvore de decisão 75

Árvore de decisãoUma árvore de decisão é uma representação de uma tabela de decisão sob a forma de uma árvore. Tem a mesmautilidade da tabela de decisão. Trata-se de uma maneira alternativa de expressar as mesmas regras que são obtidasquando 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 paraexpressar tal problema seria:

Diagrama de transição de estados

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 transição de estados• 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 doestado ou situação em que um objeto pode se encontrar no decorrer da execução de processos de um sistema. Comisso, o objeto pode passar de um estado inicial para um estado final) através de uma transição.

Diagrama de transição de estados 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.

ExemploUm 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 umtempo, é acionada a tarefa de mudar para amarelo. Então o semáforo passa de verde para amarelo. Aqui os carrosficam 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óximoestado 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çõesdo ano

Diagrama de transição de estados 77

Ver também• Engenharia de software

Referências[1] http:/ / pt. wikipedia. org/ w/ index. php?title=Predefinição:Diagramas& action=edit

Processo de desenvolvimento de softwareUm processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com afinalidade de obter um produto de software. É estudado dentro da área de Engenharia de Software, sendoconsiderado um dos principais mecanismos para se obter software de qualidade e cumprir corretamente os contratosde desenvolvimento, sendo uma das respostas técnicas adequadas para resolver a Crise do software.

Passos/Atividades Processo

Análise EconômicaVisa 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.

Análise de requisitos de softwareA 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 engenhariade software para reconhecer a incompletude, ambigüidade ou contradição nos requisitos.

EspecificaçãoA especificação é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma formamatematicamente rigorosa. Na prática, somente especificações mais bem sucedidas foram escritas para aplicaçõesbem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas de software de missão críticasejam freqüentemente bem especificados antes do desenvolvimento da aplicação. Especificações são maisimportantes para interfaces externas que devem permanecer estáveis.

Arquitetura de SoftwareA 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émassegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura também direciona as interfaces entre ossistemas de software e outros produtos de software, como também com o hardware básico ou com o sistemaoperacional.

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..

Processo de desenvolvimento de software 78

TesteTeste de partes do software, especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhandojuntos, é um papel da engenharia de software.

DocumentaçãoUma importante tarefa é a documentação do projeto interno do software para propósitos de futuras manutenções eaprimoramentos. As documentações mais importantes são das interfaces externas.

Suporte e Treinamento de SoftwareUma grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor não perceber que nãoimporta quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém daorganização irá usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas poucofamiliares. Então, como parte da fase de desenvolvimento, é muito importante o treinamento para os usuários desoftware 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çãoA manutenção e melhoria de software lidam com a descoberta de novos problemas e requisitos. Ela pode tomar maistempo que o gasto no desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar códigos quecombinem com o projeto original, mas determinar como o software trabalhará em algum ponto depois damanutenção estar completa, pode requerer um significativo esforço por parte de um engenheiro de software. Cercade ⅔ de todos os engenheiros de software trabalham com a manutenção, mas estas estatísticas podem estarenganadas. Uma pequena parte destes trabalha na correção de erros. A maioria das manutenções é para ampliar ossistemas 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 deuma forma similar.

PadrõesO processo de desenvolvimento de software tem sido objetivo de vários padrões, que visam a certificação deempresas como possuidoras de um processo de desenvolvimento, o que garantiria certo grau de confiança aos seuscontratantes.Alguns padrões existentes atualmente:• CMMI (anteriormente CMM)• SPICE• ISO 12207• MPS/Br

Modelos de ProcessoHá uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore aprodutividade e qualidade. Alguns tentaram sintetizar e formalizar a tarefa aparentemente incontrolável de escreverum software. Outros aplicaram técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento deprojeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. Como um grande número deprojetos 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.

Processo de desenvolvimento de software 79

Processo em cascataO mais antigo e bem conhecido processo é o Modelo em cascata, onde os desenvolvedores (a grosso modo) seguemestes 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 testesde sistema), implantam e mantêm. Depois que cada passo é terminado, o processo segue para o próximo passo, talcomo construtores que não revisam as fundações de uma casa depois que as paredes foram erguidas. Se as iteraçõesnã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 emfuncionalidades de software desnecessárias ou sem uso.Para isso tem que se fazer o implemento dos requisitosanteriormente analisados pelo programador.

Processos IterativosO Desenvolvimento iterativo e incremental prescreve a construção de uma porção pequena, mas abrangente, doprojeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas quepossam a levar ao desastre. O processo iterativo é preferido por desenvolvedores porque lhes fornece um potencialpara atingir os objetivos de projeto de um cliente que não sabe exatamente o que quer, ou quando não se conhecebem 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. Ofeedback é produzido por testes regulares e das versões do software desenvolvido.

Processos ágeisOs 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 adesvantagem de ter uma perspectiva de negocio que não provê uma capacidade de planejamento em longo prazo. Emessência, eles provem mais funcionalidades por custo/benefício, mas não dizem exatamente o que a funcionalidadeirá fazer.Existem várias metodologias que podem ser consideradas como abordagens ágeis, entre elas: Scrum, Programaçãoextrema, 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 passosextremamente 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 modeloem 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, eos programadores não pensem em nada mais que possa ser testado. Projetistas e Arquitetos executam umarefatoraçã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 eteste para as próximas partes mais importantes do sistema.

Método formalOs Métodos Formais são abordagens matemáticas para resolver problemas de software e hardware ao nível derequisito, 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 teoriado autômato pode ser usada para construir e validar o comportamento da aplicação para o projeto de um sistema demáquina de estado finito.

Processo de desenvolvimento de software 80

Máquinas de estado finito baseadas nestas metodologias permitiram especificar software executáveis e contornar acodificaçã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• Programação extrema• 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

Análise de requisitos de software 81

Análise de requisitos de softwareA Análise de requisitos de software é a primeira fase de desenvolvimento de software. É nesta fase que o analistafaz as primeiras reuniões com os clientes e/ou usuários do software para conhecer as funcionalidades do sistema queserá desenvolvido. É nesta fase também que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ouusuários faz com que eles nem sempre tenham claro em sua mente quais funcionalidades o software terá. Asentrevistas 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 ProgramaUma especificação de programa é a definição do que se espera que um programa de computador faça. Ela pode serinformal, neste caso ela pode ser considerada como um blueprint ou manual de usuário do ponto de vista dodesenvolvedor, 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 cuidadosamenteespecificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externasque devem permanecer estáveis.

Ver também• Métodos formais• Verificação formal• Especificação formal• Transformação programa• Contrato por projeto• Notação de maquina abstrata• Método desenvolvimento Vienna• Notação Z• Engenharia de software• Linguagem de especificação• Refinamento

Arquitetura de software 82

Arquitetura de softwareA arquitetura de software de um sistema consiste dos componentes de software, suas propriedades externas, e seusrelacionamentos com outros softwares. O termo também se refere à documentação da arquitetura de software dosistema. A documentação da arquitetura do software facilita: a comunicação entre os stakeholders, registra asdecisões iniciais acerca do projeto de alto-nível, e permite o reuso do projeto dos componentes e padrões entreprojetos.

IntroduçãoO 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 daescolha da estrutura de dados, do desenvolvimento de algoritmos e pela aplicação de conceitos de separação deescopos. Embora o termo arquitetura de software seja relativamente novo na industria, os princípios fundamentaisdeste campo vem sendo aplicados esporadicamente pela engenharia de software desde o inicio dos anos 80. Asprimeiras 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 umesforço concentrado para definir e codificar os aspectos fundamentais desta disciplina. Inicialmente um conjunto depadrões de projeto, estilo, melhores práticas, descrição de linguagens, e lógica formal foram desenvolvidas duranteeste período.A disciplina de arquitetura de software é centrada na idéia da redução da complexidade através da abstração eseparação de interesses. O glossário do site oficial SOFTWARE ENGENEERING INSTITUTE (Instituto deEngenharia de Software) [3] descreve que arquitetura de software é a estrutura ou estruturas de um sistema, comtodos os elementos de software vendo e tendo suas propriedades vistas por todos os outros elementos erelacionamentos.Sendo a arquitetura de sistema uma disciplina em maturação, sem regras claras, a ação do arquiteto é ainda umacomposição de arte e ciência. Os aspectos de arte da arquitetura de software são devido ao fato que os sistemas desoftware comerciais suportam alguns aspectos de um negócio ou missão. Como o direcionamento de negócio chavepara o suporte sistemas são descrito nos cenários como requisitos não-funcionais de sistema, também conhecidoscomo atributos de qualidade, que determinam como um sistema ira se comportar.[4] Cada sistema é único devido anatureza do negócio que ele suporta, tal que o nível dos atributos de qualidade exigidos de um sistema comocompatibilidade, extensibilidade, confiabilidade, manutenabilidade, disponibilidade, segurança, usabilidade, dentreoutros – 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 desoftware dá a direção dos passos que serão tomados e as tarefas envolvidas em cada área de especialidade e interessedo usuário, por exemplo, stakeholders de sistemas de software, os desenvolvedores de software, o grupo de suporteao software do sistema operacional, aos testadores e usuários de negocio final. Neste sentido, a arquitetura desoftware se torna a ligação das múltiplas perspectivas que um sistema traz nele embutido. O fato de que estas váriasperspectivas diferentes possam ser postas juntas em uma arquitetura de software padrão justifica e valida anecessidade de criação da arquitetura de software antes do desenvolvimento do software para que projeto alcance amaturidade.

Arquitetura de software 83

HistóriaA origem da arquitetura de software como um conceito foi primeiramente identificado no trabalho de pesquisa deEdsger Dijkstra em 1968 e David Parnas no início de 1970. Estes cientistas enfatizaram a importância das estruturasde um sistema de software e a criticidade da identificação da sua estrutura.[5] O estudo deste campo aumentou depopularidade desde o inicio de 1990 com os trabalhos de pesquisa concentrando-se nos padrões de estilo dearquitetura, linguagens de descrição de arquitetura, documentação de arquitetura, e métodos formais.[6] Muitasinstituições de pesquisa tais como a Carnegie Mellon University e a University of California, Irvine estavamrealizando muitas pesquisas no campo da arquitetura de software. Mary Shaw e David Garlan da Carnegie Mellonescreveram um livro intitulado Software Architecture: Perspectives on an Emerging Discipline em 1996, o qualtrazia a tona conceitos da arquitetura de software, tais como componentes, conexões, estilos, etc. Os esforços doUCI's (Institute for Software Research) na pesquisa da arquitetura de software foram inicialmente direcionado paraos 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 aprimeira norma padrão na área de arquitetura de software, e foi recentemente adotada pelo ISO como ISO/IEC DIS25961.

Descrevendo arquiteturas

Linguagem de descrição de arquiteturaAs Linguagens de descrição de arquitetura (LDAs) são usadas para descrever a arquitetura de software. Váriosdiferentes LDAs foram desenvolvidas por diferentes organizações, incluindo Wright (desenvolvido por CarnegieMellon), Acme (desenvolvido por Carnegie Mellon), xADL (desenvolvido por UCI), Darwin (desenvolvido porImperial College London), DAOP-ADL (desenvolvido pela University of Málaga). Elementos comuns de uma LDAsão componente, conexão e configuração.

VisõesA 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 deum 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 aindaalcançado em relação a qual conjunto de símbolos ou sistema representação deve ser adotado. Alguns acreditam quea UML ira estabelecer um padrão para representação de arquitetura de software. Outros acreditam que osdesenvolvimentos efetivos de software devem contar com a compreensão única das restrições de cada problema, enotações tão universais são condenadas a um final infeliz porque cada uma prove um notação diferenciada quenecessariamente torna a notação inútil ou perigosa para alguns conjuntos de tarefas. Eles apontam a proliferação delinguagens de programação e a sucessão de tentativas falhas para impor uma simples 'linguagem universal' naprogramação, como uma prova da tendência do software para a diversidade e não para padrões.

Arquitetura de software 84

Padrões de arquitetura• DODAF [10]• MODAF [11]• TOGAF [12]• Zachman framework [13]• Federal Enterprise Architecture [14]

Exemplos de arquiteturaHá 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

Arquitetura de software 85

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/ )

Programação de computadores 86

Programação de computadores

Pequeno programa em linguagem de programação C que imprime natela 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çãode sintaxe e indentação de código.

Programação é o processo de escrita, teste emanutenção de um programa de computador. Oprograma é escrito em uma linguagem deprogramação, embora seja possível, com algumadificuldade, escrevê-lo directamente em linguagemde máquina. Diferentes partes de um programapodem ser escritas em diferentes linguagens.

Diferentes linguagens de programação funcionam dediferentes modos. Por esse motivo, osprogramadores podem criar programas muitodiferentes para diferentes linguagens; muito embora,teoricamente, a maioria das linguagens possa serusada para criar qualquer programa. Para maisinformações sobre estes métodos, veja Linguagemde programação.

Software é um nome colectivo para programas decomputadores e dados.

Há várias décadas se debate se a programação é maissemelhante a uma arte (Donald Knuth), a umaciência, à matemática (Edsger Dijkstra), àengenharia (David Parnas), ou se é um campocompletamente novo.

Programas ou algoritmos?

Um algoritmo é uma sequência de passos pararealizar uma tarefa ou resolver um problema. Em nosso dia a dia utilizamos algoritmos para realizar nossasatividades, 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 algoritmoconcretizado. No entanto, os programas são, à excepção dos menores, visualizados mais facilmente como umacolecção de algoritmos menores combinados de um modo único — da mesma forma que uma casa é construída apartir de componentes.

Dessa forma, um algoritmo é uma descrição de como um computador pode ser levado a executar uma operaçãosimples e específica, como, por exemplo, uma ordenação. Um programa, por outro lado, é uma entidade que naverdade implementa uma ou mais operações de forma que seja útil para as pessoas.

Programação de computadores 87

Engenharia de softwareA criação de um programa de computador consiste de cinco passos principais:1. Reconhecer a necessidade de um programa para resolver um problema.2. Planificar o programa e seleccionar as ferramentas necessárias para resolver o problema.3. Escrever o programa na linguagem de programação escolhida.4. 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 nospassos 2, 3 e 4. A codificação põe ênfase no passo 3. O termo coder, por vezes usado como sinônimo paraprogramador, pode tornar-se aviltante porque ignora as capacidades necessárias para lidar com os outros quatropassos.

História

Um bug, que foi depurado em 1947.

Heron de Alexandria no século primeiro inventouteatros automatizados que usavam programaçãoanáloga para controlar os fantoches, portas, luzes eefeitos de som.

A mais antiga programadora de computadores que seconhece é Ada Lovelace, filha de Anabella e de LordByron (o poeta). Anabella transmitiu a Ada o seu amorà matemática, a qual, depois de conhecer CharlesBabbage, traduziu e expandiu uma descrição da suamáquina analítica. Muito embora Babbage nunca tenhacompletado a construção de nenhuma das suasmáquinas, o trabalho que ele e Ada desenvolveramsobre elas, garantiu a Ada o título de primeiraprogramadora de computadores do mundo (veja asnotas 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 semauxílio, incluindo a compilação e o teste, é Wallace J. Eckert. O trabalho deste homem antecede a ascensão daslinguagens de computador, porque ele usou a linguagem da matemática para solucionar problemas astronômicos. Noentanto, todos os ingredientes estavam lá: ele trabalhou um laboratório de computação para a Universidade deColumbia com equipamentos fornecidos pela IBM, completos com uma divisão de serviço de atendimento aocliente, e consultores de engenharia para propósitos especiais, na cidade de Nova York, na década de 1930, usandocartões perfurados para armazenar os resultados intermediários de seus cálculos, e então formatando os cartõesperfurados para controlar a impressão das respostas, igual ao trabalho para os censos décadas antes. Tinha técnicasde debug tais como códigos de cores, bases cruzadas, verificação e duplicação. Uma diferença entre Eckert e osprogramadores dos dias de hoje é que o exemplo do seu trabalho influenciou o projeto Manhattan. Seu trabalho foireconhecido 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 daUniversidade da Califórnia, Observatório Ladd da Universidade de Brown e Observatório Sproul da Faculdade deSwarthmore.

Programação de computadores 88

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ãoENIGMA durante a Segunda Guerra Mundial — ver Máquina Enigma.

Lista de linguagensExistem várias linguagens de programação. As 20 mais populares são:[1]

1. Java2. C3. C++4. PHP5. C#6. Visual Basic7. Python8. Perl9. Objective-C10. JavaScript11. Delphi12. Ruby13. PL/SQL14. SAS15. Pascal16. Lisp/Scheme/Clojure17. MATLAB18. ABAP19. Lua20. 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• Documentação de software• Engenharia de software• 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

Programação de computadores 89

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 SoftwareO teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação aocontexto 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, eque envolve ações que vão do levantamento de requisitos até a execução do teste propriamente dito.

Visão geralNão se pode garantir que todo software funcione corretamente, sem a presença de erros,[1] visto que os mesmosmuitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O tamanhodo projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais acomplexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se tornaimpossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade do testeacaba 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, oupode conter requisitos impossíveis de serem implementados, devido à limitações de hardware ou software. Aimplementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha é oresultado 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çãopode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na normaISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. De formageral, 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 deverificaçã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 comobase conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta metodologia estãodefinidos 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 produtofinal 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 metodologiade trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porém, além de umacrescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez maispressão por parte dos clientes para que o produto seja entregue num curto período de tempo. Este fato pode fazercom 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 obtenhaum produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de engenharia desoftware.

Teste de Software 90

Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos porentidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações eambientes 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 queserão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma disciplinadedicada 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 efinanceiros.De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhões dedólares à economia dos Estados Unidos. Mais de um terço do custo poderia ser evitado com melhorias nainfraestrutura do teste de software.[3]

PrincípiosPara Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, deforma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamenteanalisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também ascondições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a implementação epara a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de erros, enquanto aentidade 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 qualidadedo teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de regressão, quepermite quantificar a evolução da qualidade de software, mantendo e executando novamente testes realizadosanteriormente.O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência deerros 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 errosque outros.

TécnicasExistem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muitoutilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande valia para os sistemasorientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivoprincipal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas algumas dastécnicas mais conhecidas.

Teste de Software 91

Caixa-brancaTambém chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento internodo componente de software. Essa técnica trabalha diretamente sobre o código fonte do componente de software paraavaliar 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 aconstrução do componente de software, cabendo portanto avaliação de mais aspectos que os citados anteriormente. Otestador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a ligação de bibliotecas ecomponentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando casos de teste que cubramtodas as possibilidades do componente de software. Dessa maneira, todas as variações relevantes originadas porestruturas 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 deteste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica testes manuais outestes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de codificação reconhecidaspelo mercado de software. A aderência a padrões e boas práticas visa principalmente a diminuição da possibilidadede 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 sobreunidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executadomilhares ou milhões de vezes em intervalos de tempo pequenos. É na realidade de produção que a soma dosaparentes pequenos tempos de execução e consumo de memória de cada programa poderá levar o software a deixarde atender aos objetivos esperados. A técnica de teste de caixa-branca é recomendada para as fases de teste deunidade e teste de integração, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que porsua vez conhecem bem o código fonte produzido.

Caixa-pretaTambém chamada de teste funcional, orientado a dado ou orientado a entrada e saída, a técnica de caixa-preta avaliao 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 esperadopreviamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todosderivados da especificação.Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis seriamtestadas, mas na ampla maioria dos casos isso é impossível.[5] Outro problema é que a especificação pode estarambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as mesmasaceitas para o teste.[6] Uma abordagem mais realista para o teste de caixa-preta é escolher um subconjunto deentradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis que são processadassimilarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todoo subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possíveis podegerar 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 dosistema, mas casos possíveis incluem inteiros pares, inteiros ímpares, zero, inteiros positivos, inteiros negativos, omaior 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

Teste de Software 92

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 asfuncionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é insuficiente paraidentificar certos riscos num projeto de software.[7]

Caixa-cinzaA técnica de teste de caixa-cinza é um mesclado do uso das técnicas de caixa-preta e de caixa-branca. Isso envolveter acesso a estruturas de dados e algoritmos do componente a fim de desenvolver os caso de teste, que sãoexecutados como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é consideradocaixa-cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso deengenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, além de mensagens deerro.

RegressãoEssa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo ciclode teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software ou a cadaciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. Inclui-se nessecontexto a observação de fases e técnicas de teste de acordo com o impacto de alterações provocado pela novaversão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, é recomendada autilização de ferramentas de automação de teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testesanteriores possam ser executados novamente com maior agilidade.

Técnicas não funcionaisOutras técnicas de teste existem para testar aspectos não-funcionais do software, como por exemplo de acordo comnecessidades de negócio ou restrições tecnológicas. Em contraste às técnicas funcionais mencionadas acima, queverificam a operação correta do sistema em relação a sua especificação, as técnicas não funcionais verificam aoperação correta do sistema em relação a casos inválidos ou inesperados de entrada. É uma forma de testar atolerâ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 processargrandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que determina aescalabilidade do software. O teste de usabilidade é necessário para verificar se a interface de usuário é fácil de seaprender e utilizar. Entre verificações cabíveis estão a relação da interface com conhecimento do usuário, acompreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.[8] Já o teste deconfiabilidade é usado para verificar se o software é seguro em assegurar o sigilo dos dados armazenados eprocessados. O teste de recuperação é usado para verificar a robustez do software em retornar a um estado estável deexecução após estar em um estado de falha.

Teste de Software 93

Fases

Abstração do teste

Descendente Sistema

AscendenteIntegração

Unidade

Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada nocliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de teste serusada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é começar o testeno 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 omodelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro, porengenheiros 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 docódigo fonte do software, e geralmente também integra o processo de construção do software.

Teste de unidadeTambém conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades desoftware desenvolvidas (pequenas partes ou unidades do sistema).[9] O universo alvo desse tipo de teste são assubrotinas ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas de funcionamento dentrode uma pequena parte do sistema funcionando independentemente do todo.

Teste de integraçãoNa fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos componentes deum sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por exemplo, um componente Apode estar aguardando o retorno de um valor X ao executar um método do componente B; porém, B pode retornarum valor Y, gerando uma falha. Não faz parte do escopo dessa fase de teste o tratamento de interfaces com outrossistemas (integração entre sistemas). Essas interfaces são testadas na fase de teste de sistema, apesar de, a critério dogerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construído.

Teste de sistemaNa fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo asfuncionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condiçõessimilares – de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia-a-diade manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições reais deambiente, interfaces sistêmicas e massas de dados.

Teste de aceitaçãoGeralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que simulamoperações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o solicitado. Testeformal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e para permitir ao clientedeterminar 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, derecuperação de falhas, de segurança e de desempenho.

Teste de Software 94

Teste de operaçãoNessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará emambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de umaorganização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste devem serfeitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve testes deinstalação, simulações com cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema entrará emproduçã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 debancos de dados e outros softwares distribuídos em escala nacional e internacional – os testes requerem fasestambé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 nesseperíodo, como testes alfa. PRESSMAN afirma que o teste alfa é conduzido pelo cliente no ambiente dodesenvolvedor, 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 sistemadenominadas 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, odesenvolvedor geralmente não está presente. Conseqüentemente, o teste beta é uma aplicação do software numambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ouimaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com oresultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificações e depois sepreparam 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 maltestados 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 errosencontradas. Tais versões são um passo além do teste beta, sendo divulgadas para toda a comunidade.

PapéisSegue abaixo alguns dos papéis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoapode acumular mais de um dos papéis citados, de acordo com características e restrições de projetos dedesenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integração, porexemplo, 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 deprogramaçã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á oengenheiro (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çõestecnológicas, as ferramentas de teste. É também responsável pela liderança técnica do trabalho de teste e pelacomunicação entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento).

Teste de Software 95

O analista de teste é o técnico responsável pela operacionalização do processo de teste. Deve seguir as orientações dogerente de teste ou do arquiteto de teste para detalhar a forma de execução dos testes e as condições de testenecessárias. Também deve focar seu trabalho nas técnicas de teste adequadas à fase de teste trabalhada. Também nocampo de análise, o analista de ambiente é o técnico responsável pela configuração do ambiente de teste e pelaaplicação das ferramentas necessárias para tal. Esse profissional deve ser especializado em arquiteturas de solução enos sistemas operacionais e softwares de infraestrutura que regem o ambiente. Ele será responsável por tornardisponí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 respectivospassos de teste documentados pelo analista de teste e evidenciar os resultados de execução. Em casos de execuçõesde 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 decorreçã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. Eledeve observar as condições de teste e respectivos passos de teste documentados pelo analista de teste e automatizar aexecução desses testes na ferramenta utilizada. Normalmente são gerados scripts de teste que permitam a execuçãode ciclos de teste sempre que se julgar necessário, desde é claro, que sejam garantidas as mesmas condições iniciaisdo ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)

ArtefatosO processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de umareferência a um identificador ou requisito de uma especificação, pré-condições, eventos, uma série de passos a seseguir, uma entrada de dados, uma saída de dados, resultado esperado e resultado obtido. A série de passos (ou partedela) 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çãode casos de teste é chamada de suite de teste. Geralmente, ela também contém instruções detalhadas ou objetivospara 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 17de 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

Teste de Software 96

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• Qualidade de software• 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)

Documentação de softwareA documentação de software descreve cada parte do código fonte, geralmente uma função, uma classe, um simplestrecho ou módulo. Consiste também no conjunto de manuais gerais e técnicos, além de diagramas explicando ofuncionamento de um software como um todo ou cada parte dele.

Manutenção de software 97

Manutenção de softwareEm 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 doprocesso 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 emprogramas 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 desoftware a qual foi criada durante a fase de programação estruturada da ciência da computação. O outro modeloprincipal, 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 algummecanismo para documentar e rastrear os defeitos e deficiências. O software é disponibilizado com problemasporque a organização decide a utilidade e valor do software a um nível de qualidade particular pesando o impacto dedeficiências ou defeitos desconhecidos.Os problemas conhecidos são normalmente registrados em um documento de considerações operacionais ou notas deimplantação de forma que os usuários do software são capazes de contornar os problemas conhecidos e que irão serdescobertos 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áriosde software, Tão logo tais problemas sejam reportados para a organização de desenvolvimento, eles passaram a fazerparte do rastreamento de defeitos do sistema.As pessoas envolvidas na fase de manutenção de software irão trabalhar no problemas conhecidos, localizá-los, epreparar novas versões do software, conhecidas como versões de manutenção, a qual ira atualizar a documentação deproblemas.

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]

Manutenção de software 98

Referências[1] http:/ / selab. netlab. uky. edu/ homepage/ April%20Huffman%20Abran%20Dumke%20Journal%202005. pdf[2] http:/ / www. s3m. ca[3] http:/ / hepguru. com/ maintenance/ Final_121603_v6. pdf[4] http:/ / www3. interscience. wiley. com/ cgi-bin/ jhome/ 5391/[5] http:/ / www. pragmaticprogrammer. com/ ppbook/ extracts/ no_broken_windows. html

CMMIO CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ouEspecí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 procuraestabelecer 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 tantoem engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para odesenvolvimento 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 deuma empresa".

HistóricoOs 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 - umconjunto 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 ProductDevelopment CMM).

CMMI 99

DimensõesO CMM foi construído considerando três dimensões principais: pessoas, ferramentas e procedimentos. O processoserve para unir essas dimensões.

DisciplinasO processo inclui três disciplinas ou corpos de conhecimento (body of knowledges), sendo eles:• Engenharia de sistemas• Engenharia de software• 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 enfoquediferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenhariade software, mas o nível de maturidade que é diferente.

RepresentaçõesO CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organizaçãoutilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação ContinuaPossibilita à 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ívelum 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 oprocesso é construído sobre as diretrizes do processo existente, e é mantido uma descrição do processo. O penúltimonível é quando o processo é gerenciado quantitativamente através de estatísticas e outras técnicas. No último nível oprocesso gerido quantitativamente é alterado e adaptado para atender às necessidades negociais/estratégicas daempresa.A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quandojá utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelode comparação com outras empresas.

CMMI 100

Representação Por EstágiosDisponibiliza 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 2: Gerenciado / Gerido• Nível 3: Definido• Nível 4: Quantitativamente gerenciado / Gerido quantitativamente• Nível 5: Em otimizaçãoNesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos osprocessos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos osprocessos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível dematuridade três.Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando desejautilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível deconhecimento obtido por outros para sua área de atuação.

Áreas de ProcessoO modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas sãodivididas da seguinte forma:Nível 1: Inicial (Ad-hoc)

Não possui áreas de processo.Nível 2: Gerenciado / Gerido

• 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)Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

• 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 processoAs á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 15504A ISO/IEC_15504, também conhecida como SPICE, define um "processo para relatórios técnicos no assessoramentoem desenvolvimento de software", e similarmente ao CMMI possui níveis de maturidade para cada processo. OCMMI não é baseado nesta norma, mas sim compatível.

Histórico de AvaliaçõesAté o ano de 2002, os EUA tinham realizado 1,5 mil avaliações de CMMI, a Índia feito 153, o Reino Unido 103 e oBrasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcançou o nível 5 em todas as unidadesda empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber oní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 oresultado 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 doCMMI (por ano da certificação):2004• TCS (TATA Consultancy Services) Brazil2005• IBM Brazil• EDS - Electronic Data Systems• Stefanini IT Solutions2007• 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.

SPICESPICE (acrônimo de Simulated Program with Integrated Circuits Emphasis, ou Programa de Simulação com Ênfaseem Circuitos Integrados) é um software de simulação de circuitos analógicos. É uma poderosa ferramenta usada paratestar, e antever comportamento de circuitos contendo circuitos integrados, resistores, transistores, capacitores,diodos e outros componentes elétricos e eletrônicos.

HistóriaO software foi desenvolvido no ano de 1975 pelos pesquisadores Larry Nagle e Donald Petterson nos laboratórios depesquisas sobre eletrônica da Faculdade de Engenharia Elétrica e Ciências da Computação da Universidade daCalifórnia, campus de Berkeley. Tanto essa versão, como a segunda versão (criada em 1983) foram codificadasutilizando a linguagem de programação Fortran e rodados em mainframes. A partir da terceira versão, o programa foicodificado 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õesque incompatibilizou essas versões com a versão de Berkeley. As versões mais recentes incluíram interfacesgrá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 Freewarengspice [1]

tclspice [2]

LTSpice [3]

Links úteisLista de programas de simulação e projeto de circuitos eletrônicos [4]

Referências[1] http:/ / ngspice. sourceforge. net/[2] http:/ / tclspice. sourceforge. net/[3] http:/ / www. linear. com/ designtools/ software/[4] http:/ / www. terrypin. dial. pipex. com/ ECADList. html

ISO 12207 104

ISO 12207ISO 12207 é uma norma definida pela International Organization for Standardization, que se aplica em engenhariade software. Esta estabelece um processo de ciclo de vida do software, contendo processos, atividades e sãoaplicadas durante a aquisição e configuração dos serviços do sistema, de forma a melhorá-los. Esta norma tem comoprincipal 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, nosentido de processos com mínimo acoplamento e máxima coesão. Responsabilidade, no sentido de estabelecer umresponsável único por cada processo, facilitando a aplicação da norma em projetos, onde várias pessoas podem estarlegalmente envolvidas.Conforme citado anteriormente, a norma é composta por um conjunto de processos, atividades e tarefas que podemser 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 eorganizacionais devem existir independentemente da organização e do projeto que está sendo executado.Basicamente, é correspondido ao ISO 12207.

MPS/BrO MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoriada qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade domercado 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 normasestrangeiras, 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 eUruguai.O projeto tem apoio do Ministério da Ciência e Tecnologia, da FINEP e do Banco Interamericano deDesenvolvimento. No Brasil o projeto é desenvolvido pela Softex, interagindo com as universidades e com oGoverno Federal.

MotivaçãoO 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. Apartir deste ponto, podemos observar que as empresas estão buscando cada vez mais a maturidade nos seus processosde software para atingir padronizações de qualidade e produtividade internacionais, que são essenciais para asobrevivê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 paraempresas de micro, pequeno e médio porte. Então, em uma parceria entre a Softex, Governo e Universidades, surgiu

MPS/Br 105

o projeto MPS.Br (melhoria de processo de software brasileiro), que é a solução brasileira compatível com o modeloCMMI, está em conformidade com as normas ISO/IEC 12207 e 15504, além de ser adequado à realidade brasileira..

O modeloO MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS.

MR-MPS – Modelo de referência para melhoria do processo de softwareO MPS.BR apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) quesã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 deprojeto, 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 dequalidade, 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 dematuraçã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 softwareTem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresae organizações que implementaram o MR-MPS. Avaliação MA-MPS:• Equipe de avaliação: 3 a 8 pessoas, sendo:

1 avaliador líderno mínimo 1 avaliador adjuntono 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 softwareInstituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciaratravés de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase naexperiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamentode consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista deconsultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinadosno modelo e aprovados em prova específica.

Cursos e certificaçãoA 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 - C4Periodicamente, são realizadas provas em nível nacional para certificar profissionais em cada um dos cursosdescritos 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 passosO modelo MPS.Br tem como objetivo implementar o Modelo de Referência para melhoria de processo de softwareem 120 empresas. E como objetivos secundários, a disseminação em diversos locais do país, capacitação no uso domodelo e o credenciamento de instituições implementadoras e avaliadoras do modelo, especialmente instituições deensino 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ãohá uma especificidade para cada empresa e sim um mesmo modelo de referência para todas elas. O MPS.Br já é umarealidade, 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 107

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

Fontes e Editores da Página 108

Fontes e Editores da PáginaEngenharia 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, SergioKaminski, 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, Ei99003@fe.up.pt, 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çõesanó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, MauroBabinski, 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çõesanó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

Fontes e Editores da Página 109

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, 3ediçõ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, JonasAGX, 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, 6ediçõ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çõesanó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

Fontes, Licenças e Editores da Imagem 110

Fontes, Licenças e Editores da ImagemFicheiro:Crystal Clear action 1downarrow.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Crystal_Clear_action_1downarrow.png  Licença: desconhecido  Contribuidores: Abubadali, Augiasstallputzer, CyberSkull, Foroa, Juliancolton, Rocket000, 6 edições anónimasFicheiro:Crystal Clear action 1uparrow.png  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Crystal_Clear_action_1uparrow.png  Licença: desconhecido  Contribuidores: Abubadali, Augiasstallputzer, CyberSkull, Rocket000Imagem: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, 1edições anónimasImagem:cquote2.svg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Cquote2.svg  Licença: Public Domain  Contribuidores: Editor at Large, InfrogmationImagem:Processo_es.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Processo_es.jpg  Licença: Public Domain  Contribuidores: User:FurutajpImagem:coarse grain.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Coarse_grain.jpg  Licença: GNU Free Documentation License  Contribuidores: LeonardoGImagem:waterfall diagram.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Waterfall_diagram.jpg  Licença: GNU Free Documentation License  Contribuidores: Originaluploader was Ei99003@fe.up.pt at pt.wikipediaFicheiro: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-Sharealike3.0  Contribuidores: Elvis PellizariFicheiro: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 PellizariFicheiro: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 PellizariImagem:Dfd.JPG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Dfd.JPG  Licença: Public Domain  Contribuidores: Mtheus, NewmanbeArquivo: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ónimasImagem:Tabeladecisao.JPG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Tabeladecisao.JPG  Licença: Public Domain  Contribuidores: 555, MtheusImagem:Arvoredecisao.JPG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Arvoredecisao.JPG  Licença: Public Domain  Contribuidores: Mdd, MtheusFicheiro:semaforo.jpg  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Semaforo.jpg  Licença: Public Domain  Contribuidores: SmartkidsFicheiro:Transicaoestado.JPG  Fonte: http://pt.wikipedia.org/w/index.php?title=Ficheiro:Transicaoestado.JPG  Licença: Public Domain  Contribuidores: MtheusFicheiro: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ónimasFile: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.

Licença 111

LicençaCreative Commons Attribution-Share Alike 3.0 Unportedhttp:/ / creativecommons. org/ licenses/ by-sa/ 3. 0/