texto-geral-processos-desenvovimento

- Multiprocessamento: Onde distribui para mais de um processador.

Processo de Desenvolvimento de Software Aula 1 1.

O que é software?

Quanto à quantidade de usuários:

É uma seqüência de instruções organizadas de maneira que ao iniciá-lo tem como objetivo executar, manipular ou modificar um dado, informação ou acontecimento.

O Software por sua vez também é considerado um produto que fora desenvolvido pela Engenharia de Software, onde inclui, além do programa propriamente dito como manuais e especificações.

Para o desenvolvimento do produto/programa é necessário escrevê-lo utilizando uma linguagem de programação. Utilizando a linguagem escolhida, está será responsável por converter o código em linguagem de maquina, ou seja, em um formato que será compreendido pelo processador.

Existem basicamente duas linguagem de programação.

classificações

para

- Monousuário: onde somente e permitida à utilização de um usuário de cada vez.

- Multiusuário: onde vários usuários utilizam ao mesmo tempo.

- Software Aplicativos: São os diversos outros programas que tem interface direta com o usuário, como por exemplo, editores de texto, planilhas eletrônicas, navegadores, dentre outros.

Hardware  Sistema Operacional  Linguagem de programação  Software Aplicativo  Usuário.

2.

Características e aplicações do software.

a

O software pode ser classificado de acordo com a sua licença de publicação, ele pode ser, dentre outros:

- Estruturada: Elementos de código em formato de blocos, que se interligam através de três estruturas básicas: seqüência, onde os passos são seguidos de forma seqüencial (tarefa um finaliza, entra tarefa dois), seleção, onde os passos podem ser executados baseados em um tratamento lógico (IF, THEM, ELSE) e iteração, onde os passos podem ser repetitivos até uma condição for atingida.

- Software gratuito ou freeware: programa de computador cujo seu uso não implica no pagamento de licença de uso - Software livre: programa de computador cuja sua utilização, copia e distribuição não possuem restrição. É comum o código fonte estar disponível para anuviá-lo - Shareware: programa de computador que possui limitações, de tempo e/ou funcionalidades. Ao final do tempo estabelecido, programa pode requisitar o pagamento para o uso do software completo, pode continuar utilizando sem todas as funcionalidades, ou interromper o seu uso.

- Adware: programa de computador que executa automaticamente algum tipo de publicidade, após sua instalação ou durante sua utilização - Demo: fração de um programa, onde vira um material promocional para dar oportunidade de o produto ser avaliado.

- Trial: programa semelhante ao demo, mas com funcionalidades disponíveis por tempo determinado.

- Comercial: programas que paga-se uma taxa de licenciamento para sua utilização.

- Orientada a Objeto (OO): Os elementos de código em formato de objetos que se interligam. Classe (tipo de objeto), atributos (variáveis que estão dentro de cada objeto da classe), e método (ação que a classe pode realizar) Além da linguagem de programação, o software também pode ser classificado como: - Software de sistema: São chamados de sistemas operacionais, e são responsáveis por operar os demais periféricos que estejam conectados ao hardware.

Podem ser classificado quanto ao gerenciamento de processos, como: - Mono tarefa: Onde executa somente um processo de cada vez: - Multitarefa: Onde os processos são compartilhados e enfileirados a espera do processador. São distribuídos de modo que parecem ser executados simultaneamente

3. Fluxo de dados Dado: matéria prima inicial, conjunto de fatos de forma primaria.

Informação: Conjunto de dados, ou fatos, organizados de forma que adquirem valor.

1

Conhecimento: São regras, diretrizes ou procedimentos utilizados para manipular ou organizar dados para tornálos úteis e com um fim especifico.

Fluxo básico de processamento de dados: Entrada (DADOS) (informação)



Processamento



Saída

Na fase de processamento, o software tem papel fundamental na transformação de dado para informação.

Informação  Base do Conhecimento EXERCÍCIOS 1. Marque abaixo a única alternativa em que todas as linguagens são Orientadas a Objeto? ( ( ( (

) C#, Java, C ) C, COBOL, Pascal ) C++, C#, Java ) Java, Fortran, Pascal

Viabilidade do Cronograma: Visa atender os requisitos de tempo, para os prazos estabelecidos. O levantamento deve ser baseado na viabilidade técnica em relação ao prazo estipulado. Prazos obrigatórios são mais difíceis de serem negociados.

Viabilidade Econômica: Visa atender os requisitos financeiros do projeto/produto. Considerada a mais critica, ela consistem em julgar se o projeto será deficitário, ou se os custos de sua implementação não terão os benefícios desejados.

Esta fase também é chamada de analise de custobenefício.

2. De acordo com a licença de uso de software marque a opção errada. ( ) Software livre é um software com código aberto. ( ) Freeware é um software livre. ( ) Software Trial, tem prazo para as funcionalidades pararem de funcionar. ( ) Adware é uma licença onde pode se automatizar o anuncio de um patrocinador.

Algumas definições de http://pt.wikipedia.org/wiki/Software

Viabilidade Operacional: Visa atender os requisitos para a aceitação do produto ou problema apresentado.

Levantamento deve ser relacionado com a aceitação da solução proposta, e como os agentes se sentirão em relação a ela.

Software:

Tipos de Custo: Operacional (Fixo e Continuo), no desenvolvimento do projeto.

Operacional – Pessoal, Manutenção, Luz. Desenvolvimento do projeto – Aquisição de novos softwares, custos de instalação, atualização.

Analise ROI ( Return of Investiments ) – Percentual que mede a relação entre quanto se ganhou e quanto se investiu.

ROI = ( Total de Lucro ou benefícios – Total de custo ) / Total de Custo Quanto maior for à taxa, melhor é o ROI

Aula 2 1.

Atividades para analise de requisitos

Estudo de Viabilidade: Estudo inicial para saber se vale à pena desenvolver a idéia. O estudo deve oferecer base para ajudar na decisão.

- O projeto/produto pode ser feito?

- O projeto/produto beneficiara os clientes interessados?

- Existe alternativa?

Tipos de Viabilidade: Técnica, Operacional, Cronograma e Econômica.

Viabilidade Técnica: Visa atender os requisitos técnicos do produto a ser desenvolvido. Levantamento deve ser relacionado com a tecnologia envolvida no processo de desenvolvimento.

2.

Tipos de Requisito.

Requisito: É uma condição ou necessidade de um usuário para resolver um problema ou alcançar um objetivo.

Também pode ser uma necessidade de estar presente em um sistema para satisfazer uma condição, contrato, padrão, ou especificação devida.

Requisitos do Usuário: Definições sobre a função do sistema e restrições sob os quais ele deve operar. O formato é em linguagem comum, visando entendimento do cliente/usuário.

2

Requisitos do Sistema: Definição estruturada, e detalhada do serviço que será feito no sistema/produto. O formato é em contrato de prestação de serviço entre o cliente e o fornecedor.

Requisitos funcionais: Descreve as funcionalidades do sistema. Esta diretamente ligada às especificações da tecnologia envolvida, do perfil do usuário, do tipo do sistema.

Ex: [RF 0023] Usuário não pode acessar o Banco de Dados financeiro [RF 0059] Sistema deve oferecer opção para usuário escrever observação nos documentos.

Requisitos não funcionais: Descreve propriedades e restrições para atender a finalidade do sistema. Por serem mensuráveis, deve haver uma medição ou referencia para cada requisito elicitado.

Alguma propriedade e suas medições Velocidade Tamanho Confiabilidade Facilidade de Uso

Transações/segundo Mbytes Tempo médio de falhas Treinamento

De acordo com sua classificação podem ser: Requisitos não funcionais de produto: O produto deve se comportar de acordo com as classificações medidas. ( velocidade, confiabilidade, tamanho..)

Ex: [RNF 0008] Consulta no banco de dados financeiro não deve ultrapassar 3s.

Requisitos não funcionais organizacionais: Deve seguir regras definidas pela corporação ou empresa, seguir procedimentos da própria organização. (padrão de processo, padrão de documentação, padrão dos requisitos para implementação, .. ) Ex: [RNF 0236] Os documentos da matriz de responsabilidade devem seguir o padrão XPTO 123.

Requisitos não funcionais externos: Deve seguir a o processo de desenvolvimento atendendo bases da legislação nacional e internacional.

Ex:[RNF 0129] As informações de cadastro dos usuários não deve ser acessada por nenhum operador.

Requisitos de Domínio: São requisitos referente ao produto ou aplicação, que deve ser responsável por corrigir, restringir ou estabelecer novas funções para que o sistema possa operar de forma satisfatória.

Ex: [RD 0291] Deve haver uma interface padrão para a consulta do bando de dados secundário, que terá como base o padrão RDF-763X 3.

Técnicas de Elicitação

Entrevistas: Utilização na analise de problema e na engenharia de requisitos, com o objetivo de entender as perspectivas do cliente/usuário. Entender quem são os agentes, necessidades, o problema e a solução Questionários: Forma de utilização utilizando perguntas referentes ao sistema. Utilização de hipóteses para as relevâncias.Pode ser utilizado após a entrevista, Casos de Uso: Identificação dos agentes que agem no sistema, das interfaces que o sistema/produto possuirá, validação de pré-requisitos. Representação visual ao invés de textual.

Brainstorm: Ou tempestade de Idéias, faz o levantamento de idéias, onde cada idéia sugerida pode combinar na propositura de uma nova. Atividade de livre imaginação, e deve ser tratada sem criticas ou debates.

EXERCÍCIOS 1. Que tipo de viabilidade também é chamada de analise de custo-benefício? (a) Técnica (b) Operacional (c) Cronograma (d) Econômica Resposta d 2. Marque a opção que não representa um requisito não funcional. (a) Organizacionais (b) De sistema (c) Externos (d) Domínio Resposta b http://pt.wikipedia.org/wiki/Análise_de_requerimento_d e_software Aula 3 3

4.

Conceitos de Modelagem

Modelagem: serve para verificar requisitos recém obtidos da aula tornarão precisos e detalhados o atividades do próximo passo desenvolvimento de software.

- Identificação dos relacionamentos: Ajuda a filtrar e refinar as classes. Podem se por associação ou agregação a qualidade dos anterior, estes se suficiente para as no processo de

Analise: Atividade que utiliza o conceito de orientação a objeto, utilizando a UML como notação. Objetivo modelar o problema, não à solução.

UML: Unified Modeling Language, linguagem de modelagem unificada, utilizada em engenharia de software para visualizar o desenho do sistema e a intercomunicação entra objetos.

5. Objeto e Classe Objeto: Estrutura de dados encapsulada por procedimentos. Essa estruturas são os atributos e operações.

Classe: um conjunto de objetos similares agrupados, onde a etapa de analise está mais voltada para sua realização.

6. Tipos de Analise.

Analise Estrutural: Tem como objetivo modelar aspectos estáticos de um problema, utilizando o modelo orientado a objeto. É utilizado em conjunto com detalhamento de requisitos para visualizar e fornecer base para identificar soluções para os requisitos apresentados. .

Atividades dentro de objetos: - Identificação de Classes: Identificar quais são as classes chaves. Fazer o levantamento com base em suas responsabilidades e colaborações. Utiliza-se em larga escala o cartão CRC (Class-Responsability-Collaborator).

- Organização das classes: Organizar as classes em 3 tipos: Entidade – representam conceitos do domínio do problema, são herdadas dos modelos de negocio.

Fronteira – representam interfaces externas que estão dentro do produto, como por exemplo, interface de usuário, conexão com outros sistemas. Facilita o desenho das interfaces.

Controle – são organizações que não pertencem à entidade e nem fronteira. Normalmente é associada a um caso de uso.

Associação – indicam a relação entre duas classes, onde os objetos de uma classe consegue obter informações da outra que foi associada.

Agregação – indica um associação, mas com a classe se apossando das informações do um objeto da outra.

- Identificação dos atributos: Onde cada classe é atribuído um atributo responsável por tomar alguma ação Analise Comportamental: Aplicado depois que os requisitos forem detalhados, validando-os e indicando as dificuldades de implementação, no plano de conceito.

Diagrama de Interação: Mensagens que são trocadas ao longo do tempo, para execução de alguma tarefa Mensagens e Operações – representam um mecanismo de interação, ou seja, um objeto só poderá receber uma mensagem invocada por uma classe. A mensagem tem as seguintes partes: Receptor – o que recebe a mensagem, Operação – função de execução do receptor, Parâmetro – dados necessários para a operação Interação – como as mensagens trafegarão, para a execução de uma tarefa.

Diagrama de seqüência – ordem temporal das ações que serão executadas.

- Identificação das operações: todas as mensagem devem se mapeadas para executarem alguma operação. Podem ser Incluir, Alterar, Excluir, dentro outras.

EXERCÍCIOS Na analise de objetos o que fazer para definir as classes chaves? ( a) (b ) ( c) ( d)

Utilizando cartões tipo CRC Desmontando o Objeto Fazendo uma analise de requisitos.

Analisando o seu desenho

Reposta: a 3. Marque a opção que não representa uma organização de classe ( a ) Entidade 4

( b ) Fronteira ( c ) Controle ( d ) Parâmetro

em conjunto com a documentação voltada para usuários, no caso de desenho externo, ou documentação do código do programa, no caso de desenho Interno.

Reposta: d

8.

SAIBA MAIS

Nesta fase, é comum fazer uso de processos que já foram definidos e utilizados em outras fases do produto ou sistema. O processo de reutilização visa redução do desperdício de tempo e conseqüentemente dinheiro, visto que a cada iteração os defeitos que havia em outras fases, já foram sanados.

O que é UML? http://pt.wikipedia.org/wiki/UML Informações sobre analise estruturada e diagramas auxiliares: http://pt.wikipedia.org/wiki/ Análise estruturada Aula 4 7.

Reutilização.

A reutilização pode ser de: Código: Reutilização de parte de código de programa.

Problema X Solução

Problema: Levantamento de informações na fase de análise e requisitos define-se como um problema, ou meta a ser alcançada.

Solução: Após levantamento de análise, a documentação do desenho exemplifica a solução que será tomada para resolução do problema.

Modelo de desenho de acordo com a perspectiva entre as partes interessadas e a solução a ser apresentada.

Desenho externo: Visão que os usuários terão da solução ou produto, e a forma com que eles se interagirão.

Desenho Interno: É a maneira como o sistema interage, com outros produtos ou sistemas. Podem conter parte física, lógicas, interconexões com outros sistemas e produtos, interna ou externamente.

O nível de abstração e agregação dos elementos dos sistemas pode ser: Nível Estratégico, ou Desenho Arquitetônico: É o corpo da arquitetura do sistema a ser implementado. Com base nesse desenho já da para saber se o sistema atenderá os requisitos e os custos relacionados do projeto.

Nível Tático, ou Desenho Lógico: É a aplicação das decisões tomadas no nível estratégico. A solução contemplará a reutilização, ou não, de componentes, que serão desenvolvidos para ele, buscando satisfazer os requisitos do produto.

Nível Operacional, ou Desenho Detalhado: É o comportamento de cada componente. É desenvolvido

- Reutilização de objeto: Modulo de código binário - Reutilização fundamentais

de

classe:

bibliotecas

e

classes

- Reutilização de plataforma: camada de arquitetura Desenho: Aproveitamento de idéias, para solução de problemas encontrados no desenho, é comumente baseada em classes abstratas, derivados por herança de outra classe, EXERCÍCIOS 4. No contexto do desenho externo, para quem são criadas as informações? (a) Partes físicas do sistema (b) Usuários do sistema (c) Partes lógicas do sistema (d) Interconexões com outros sistemas Resposta: 5.

Como também é conhecido o Nível Operacional?

(a) Desenho Lógico (b) Desenho Arquitetônico (c) Desenho Físico (d) Desenho Detalhado Resposta: SAIBA MAIS Arquitetura de Software: http://pt.wikipedia.org/wiki/Arquitetura_de_software 5

Aula cinco 9.

Testes de Software

Teste: processo de findo com intenção de encontrar um erro Objetivo de teste: Encontrar um erro que ainda não foi descoberto. Um teste bem sucedido corresponde à descoberta de um erro não previsto.

Critério de Teste: Definição de uma métrica onde, após a analise do comportamento do sistema, atenda o critério.

Procedimento de Teste: Conjunto de instruções para a realização de testes.

“Script” de Teste: É uma representação definida de um procedimento de teste.

Teste de Sistemas: Analise e verificação de todos os componentes do sistema. (hardware e software). Validar se estão em conformidade com os requisitos anteriormente definidos. Para uma melhor analise, o teste deve ser feito por uma equipe independente, diferente das equipe desenvolvedora.

Teste Caixa preta (“Black-box Testing”): Teste que não levam em conta os mecanismos e definições internos do sistema. O objetivo principal está no resultado da saída de dados do sistema, mediante a entrada definida de dados.

Teste Caixa Branca (“White-box Testing”): Teste que leva em conta a sua estrutura interna de construção. Os mecanismos internos do sistema serão analisados e suas representações lógicas. O teste da caixa branca não exclui a necessidade do teste da caixa preta, uma vez que o funcionamento interno do sistema ou produto pode ser aceito logicamente, mas resultar numa saída diferente da esperada.

10. Modalidade de Testes a. Quanto à utilização do código Testes Estáticos: São testes realizados pela analise do código fonte. O tipo de analise é visual, podendo haver um questionário para acompanhar os testes, inspecionando o código desenvolvido pela equipe de programação.

Testes Dinâmicos: São testes baseados na execução do código do programa. Os testes seguem também um questionário, com base nos aspectos estruturais e funcionais do programa. b. Quanto ao objetivo na busca pelo erro Teste de Unidade: Teste realizado em um modulo ou alguns módulos definidos, que representam uma única unidade. A determinação da quantidade de módulos a serem testados, esta contido na documentação de projeto.

Teste de Integração: Teste para identificar erros durante a integração e interação entre os módulos, ou unidades do sistema.

Teste de Validação: Teste realizado após a integração de todos os módulos do sistema.

EXERCÍCIOS 6.

Um analista esta testando um novo produto, mas ao executar a tarefa programada, a saída deu diferente da que estava documentada, Esse é um exemplo de? ( ( ( (

) ) ) )

Teste Caixa Branca Teste Caixa Preta Testes Estáticos Critério de Teste

7.

Um analista esta testando um novo produto, ele recebeu da equipe de desenvolvimento um documento com etapas, códigos fonte e métricas do software a serem testados. Esse documento representa? ( ( ( (

) Teste Caixa Branca ) Teste Caixa Preta ) Teste Dinâmico ) Procedimento de Teste

SAIBA MAIS Arquitetura de Software: http://pt.wikipedia.org/wiki/Teste_de_Software Aula 6 11. Implementação e Desenho

6

Implementação: processo que realiza a transformação do desenho em diversos tipos de componentes de código de programação.

Desenho: Etapa do processo de desenvolvimento de software já estudada anteriormente.

Código de pro gamação: pode ser dividido em 3 tipos Código Fonte: Conjunto de instruções, gerados através de uma linguagem de programação, de maneira lógica e estruturada, após o processo de compilação ou interpretação, se transformará em código objeto.

Código Objeto: Resultado da compilação do código fonte.

Código de maquina: Seqüência binária de ações diretamente direcionadas para o processador da maquina.

Compilador: Programa que faz uma leitura do código fonte, desenvolvido em uma linguagem de alto nível, transcreve para um novo tipo de linguagem, chamada de baixo nível.

Interpretador: Programa que alem de fazer a leitura do código fonte e transformá-la em código objeto, transforma-o um código executável.

Linguagem de baixo nível: Linguagem de programação que utiliza a arquitetura do processador para executar as ações. Esta linguagem é a que mais se aproxima dos códigos de execução direta do processador, ou seja, linguagem de maquina.

Linguagem de alto nível: Comumente chamada de linguagem de programação, esta linguagem se aproxima mais com a linguagem humana, ou seja, linguagem com um padrão de entendimento humano bem definido. Para essa linguagem não é levado em consideração à arquitetura do computador, nem as características do processador e seus registradores, visto que na fase de interpretação ou compilação, estes programas transformarão em linguagem de baixo nível, ou de maquina.

12. Classificação das Linguagens A classificação das linguagens segue uma ordem cronológica.

Linguagem de primeira geração: Desenvolvido no inicio da era dos computadores, esta linguagem é interpretada pelos microprocessadores. Cada microprocessador possui uma linguagem própria de entendimento, o que pode

ocasionar erros de programação em processadores de uma mesma família de fabricantes. Ex: Assembly Linguagem de segunda geração: Surgidas em meados dos anos 50, foram consideradas as primeiras linguagens de alto nível, visto que eram de fácil entendimento e, portanto eram consideradas mais humanas. Ex: COBOL, Pascal, FROTRAN. Linguagem de terceira geração: Em meados dos anos 80, surgiram o conceito de programação estruturada, e a programação orientada a objeto.

Linguagem de quarta geração: São características de essa linguagem dar suporte para execução de rotinas auxiliares às linguagens de terceira geração. Ex: Linguagem de consulta, utilizada para conexão com banco de dados.

Documentação: Uma vez que o desenho será à base da implementação, o processo de documentação de uso do produto passa a ter importância nessa fase, onde a documentação e programação devem andar lado a lado.

EXERCÍCIOS 8.

Uma analista esta rodando um programa em sua linguagem de programação, no final da execução, o resultado foi um arquivo executável. Qual o tipo de programa esse analista esta usando? ( ( ( (

) ) ) )

DOS Compilador Interpretador Assembly

9.

Qual das linguagens abaixo é considerada a de mais baixo nível? ( ( ( (

) Visual C++ ) Assembly ) C# ) PERL

SAIBA MAIS Compilador: http://pt.wikipedia.org/wiki/Compilador Interpretador: http://pt.wikipedia.org/wiki/Interpretador Aula 7 7

13.

Documentação do produto.

Documentação: processo que adota métodos e formatos padronizados para cada família de produtos correlatos.

Manual do Usuário: Documento com formato adequado ao perfil do publico que utilizará o sistema ou produto. A linguagem deve se clara e os termos e construções devem estar de acordo com o nível cultural e técnico do usuário final.

Manual de Introdução: descrevem as funcionalidades do sistema, como o usuário pode utilizar os pré-requisitos necessários para funcionar.

Manual de referencia: Descreve facilidades do uso do sistema, informa os erros que podem ocorrer e como agir quando encontrá-los.

Documento de Instalação: Descrição de como instalar o sistema, plataformas de operação, pré-requisitos necessários.

Referencia Rápida: Documento com um resumo das funcionalidades, atalhos de procedimentos, principais funções utilizados, e mensagem de erro mais comuns.

Uma referencia básica pra o padrão de manual é o IEE Std. 1063 – 2001 Documentação do software: processo que descreve as partes do código fonte, requisitos necessários, arquitetura do sistema. Essa documentação é bastante útil para o desenvolvedor no processo de melhoria ou correção do produto.

Manutenção do Software: Consiste em corrigir defeitos ou deficiências encontrados pelos administradores ou usuários do produto. A manutenção também pode ser considerada um processo de melhoria das funcionalidades do software.

Refatoração: Dentro do processo de manutenção do software, existe a refatoração, que tem como objetivo melhorar um sistema de software, modificando sua estrutura interna, sem alterar o comportamento interno.

Separação Estática: Processo pelo qual identificam variáveis que apresentem algum tipo de não conformidade com o programa. O processo leva a identificação do código onde à variável afeta sua funcionalidade.

Cronogramas: Documentação utilizada por gerentes de projetos, executivos e gerentes funcionais, para acompanhar o andamento do projeto.

Relatórios: Documentação de acompanhamento de recursos utilizados durante o andamento do projeto.

Padronização de processos: Estabelece o formato e a cadencia de como o processo deve ser implementado.

Essa padronização pode seguir o formato definido pela empresa, organização, ou um formato mais abrangente, como nacional ou internacional.

Comunicação: Estabelece a forma de comunicação entre os membros projeto.

Documentos Técnicos: Descreve estratégias de como chegar ao resultado final, registram os erros, problemas e idéias que ocorrem durante o projeto, e as razões que foram utilizadas para as tomadas de decisões.

EXERCÍCIOS 10.

Um novo executivo de uma grande empresa multinacional, acabou de assumir o cargo. Ele gostaria de obter informação sobre os prazos e andamentos das atividades de desenvolvimento do sistema que sua empresa esta desenvolvendo. Qual documento, o gerente de projeto, deve enviar para o executivo? ( ( ( (

) ) ) )

Manual do Usuário Documentação do Software Cronograma Relatório

11.

O mesmo Executivo precisa saber o quando foi gasto com andamento do projeto. Qual documento, o Gerente de projeto, deve enviar? ( ( ( (

) Cronograma ) Relatório ) Refatoração ) Não tem como saber.

SAIBA MAIS Manutenção de Software: http://pt.wikipedia.org/wiki/Manutenção_de_software Refatoração: http://pt.wikipedia.org/wiki/Refatoração Aula 8

14.

Documentação do Processo

15.

Modelo Inicial.

8

Modelo Balburdia: Metodologia de desenvolvimento de software onde os antigos desenvolvedores baseavam-se em suas próprias experiências para desenvolver os softwares. Esse modelo podia ser descrito por um ciclo de 2 fases: Implementação e correção.

Codifica-Remenda: Metodologia semelhante ao modelo balburdia, onde após a implementação, os erros e atualizações eram descobertos durante a sua utilização.

Os ajustes que precisavam se feitos eram programados em caráter de urgência, gerando insatisfação e pressões de usuário. Por conseqüência a qualidade e a confiabilidade do sistema eram sempre postos a prova.

16.

Modelo Cascata.

Desvantagens do Modelo em cascata: O modelo em cascata visa o encerramento de uma fase, ou etapa, para o inicio da outra subseqüente. Durante um projeto, algumas atividades estão em constante mudança, uma delas são os próprios requisitos. Se o processo somente pode ser seguido após a finalização da etapa anterior, este nunca irá se encerrar.

Modelo em cascata com realimentação: Modelo que permite a revisão de fases anteriores e a superposição entre as fases. Esse modelo é uma variante do modelo cascata tradicional. Esse modelo permite a realimentação, ou seja, correções que surgirem durante outras fases do processo.

Ciclo de vida do projeto: Conjunto de atividades descritas e ordenadas, onde segue um fluxo continuo de informações e relacionamentos, para auxiliar o acompanhamento de um projeto.

Modelo de processo cascata: Primeiro modelo conhecido em engenharia de software. Consistem num modelo linear, onde cada atividade tem ser completada antes de iniciar a próxima.

Ex: Abaixo. A etapa de Projeto só poderá ser iniciada após a finalização da etapa de requisitos.

Vantagens do Modelo cascata com realimentação: Possibilidade de correção de erros durante o processo de desenvolvimento de software.

Desvantagens: dependendo da quantidade de revisões, realimentações, o processo pode se tornar difícil de gerenciar.

EXERCÍCIOS 12.

Marque a única característica que NÃO pertence ao modelo de processo cascata?

Vantagens do Modelo Cascata: Para pequenos projetos que não necessitem de padronizações e documentações, o modelo em cascata pode ser útil, pois o ganho de tempo na fase de planejamento pode ser um diferencial no tempo total do projeto.

( ) Seqüencial. ( ) Inicio da fase posterior somente quando a fase anterior é completa. ( ) Possibilidade de correção de erros na fase de requisitos ( ) Após a analise de requisitos terminada começa a fase de projeto.

13.

Marque a única característica do modelo cascata com realimentação ?

9

( ) Modelo pelo qual não se pode retornar às fases anteriores para correção. ( ) Modelo que pode retornar à fase anterior para correção ( ) Modelo é seguido baseado em experiência dos próprios desenvolvedores. ( ) Caracteriza-se por 2 etapas, Implementação e correção.

SAIBA MAIS

19.

Modelo Iterativo e Incremental

Modelo Iterativo e incremental: Metodologia de desenvolvimento de software onde define um subconjunto de requisitos, e utiliza o modelo em cascata para sua realização. Cada porção do ciclo segue o projeto de arquitetura inicial, como guia, mas com uma abordagem bem menor.

Uma vez satisfeitos os requisitos, e os objetivos da iteração forem completos, o desenvolvimento segue para a próxima iteração.

Modelo em Cascata: http://pt.wikipedia.org/wiki/Modelo_em_cascata Modelos de Ciclo de vida: http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida Aula 9 17.

Modelo Iterativo.

Processo Iterativo: Modelo pelo qual se baseia na idéia de melhoramento ou refinamento aos poucos.

Caracteriza-se pela seleção de uma parte do projeto, onde o grupo de desenvolvedores identifica ,especifica, implementa e testa a iteração. Se esta atender as especificações, a equipe passa para a próxima iteração.

(fonte: http://wiki.sj.cefetsc.edu.br/wiki/index.php/Imagem:Ciclo_de_ Vida_Iterativo.PNG)

18.

(fonte: http://wiki.sj.cefetsc.edu.br/wiki/index.php/Imagem:Iterativo_ e_incremental.jpg)

20.

Modelo Espiral

Prototipação: Criação de um modelo para ser analisado e desenvolvido a partir dele. . O Analista coletará informações (requisitos), para um mini projeto (protótipo), concentrando-se nas entradas e saídas do software, bem como em suas iterações, entre usuário e programa. Após a criação e aceitação do protótipo o produto final será desenvolvido.

Modelo Incremental.

Processo incremental: Modelo pelo qual se baseia na idéia de aumento do âmbito do sistema, ou seja, na criação de novas versões para o modelo proposto.

Início

Projeto

Construção

rápido

protótipo

Obtenção

Avaliação

dos

protótipo

requisitos

Fim (fonte: http://wiki.sj.cefetsc.edu.br/wiki/index.php/Imagem:Ciclo_de_ Vida_Incremental.PNG)

Construção

Refinamento

Produto

Protótipo

Modelo Espiral: O Modelo espiral se assemelha com o prototipação, mas inclui um fator, a analise de risco.

10

Funciona de forma iterativa, incremental mas com uma etapa onde pode ser tomada a decisão de interromper ou não o processo. fonte: http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html)

EXERCÍCIOS 14.

Fazendo uma analogia a um artista que esta pintando um quadro. À medida que o tempo passa ele aperfeiçoa a cor, o detalhe do traço dentre outros. Qual processo abaixo melhor representa esse artista. ( ( ( (

) ) ) )

Incremental Iterativo Cascata Codifica-remenda

15.

Fazendo analogia a uma construção. Inicialmente uma casa possuía 3 divisões. À medida que o tempo ia passando foram incluídos novos aposentos nessa residência. Hoje ela já possui 2 pavimentos com 6 divisões cada. Qual o processo abaixo melhor representa a construção de uma casa? ( ) Incremental ( ) Iterativo ( ) Cascata ( ) Codifica-remenda SAIBA MAIS Modelo em Iterativo e incremental: http://wapedia.mobi/pt/Desenvolvimento_iterativo_e_in cremental Modelos de Ciclo de vida: http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida Aula 10 21.

Processo de desenvolvimento Ágil.

Método Ágil: É um conjunto de diretrizes e metodologias que cria uma estrutura conceitual para desenvolver projetos de desenvolvimento de software.

Baseado em um manifesto criado por programadores veteranos, e que já tinham passado por inúmeras experiências diferentes no campo de desenvolvimento de software, o Manifesto Ágil (http://www.agilemanifesto.org/) tem como foco as pessoas e não as ferramentas.

valores (comunicação, simplicidade, feedback e coragem) o modelo propõem uma serie de praticas focados em pessoas, ou seja, na equipe de desenvolvimento.

Algumas práticas do método XP: - Reuniões em pé: Utilizados par anão perder o foco no assunto.

- Programação em par: Formado por uma dupla, no papel de iniciante e do instrutor, Como utilizam um único computador, o código passa automaticamente pelo crivo de duas pessoas.

- Testes de aceitação: Testes com validação do cliente.

- Pequenas versões: Pequenas versões aceitas pelo cliente ajudam na aceitação do programa completo - Ritmo Sustentável: Utilizar o tempo de trabalho dentro do especificado. Sem horas adicionais. (40 horas por semana) - Padrão de codificação: Estabelecimento de regras de código de programa.

- Posse coletiva: O código fonte não pertence a ninguém, é de todos e todos podem utilizá-lo sem necessidade de permissão.

Método Scrum: Metodologia que tem como filosofia o manifesto ágil. Possui papel bem definido para as atividades durante todo o processo. Uma vez levantados as questões a serem trabalhadas, é determinado um período de tempo para a realização de um determinado requisito. Durante esse intervalo são feitas reuniões diárias para acompanhamento do andamento das atividades.

Características do modelo Scrum.

Product Backlog – Lista de itens das quais o cliente deseja que sejam implementados.

Sprint Backlog – Analise feita do Product Backlog. Cada requisito é analisado, interpretado e informado a equipe como será implementado.

Sprint – Período definido para cada finalização de requisito.

Scrum – Reunião diária para analise de andamento do projeto Scrum Máster – Responsável por coordenar o Scrum e ajudar a atender os impedimentos que possam ocorrer, na tentativa de não estourar o Sprint

Método XP: Também conhecido como eXtreme Programming, é um método que pertence à metodologia ágil de desenvolvimento de software. Baseado em 4 11

Produc t Backlo

Ao longo das fases, o projeto sofre diversas iterações e as disciplinas têm diferentes responsabilidades durante o projeto.

Reunião Diária

g

Sprint Backlog

Spri nt

Fim do Sprint

22.

Processo Unificado.

RUP – Também conhecido como Rational Unified Process, é um processo que faz parte da engenharia de software.

Ele é baseado em disciplinas, onde cada uma distribui tarefas e responsabilidades para os envolvidos no desenvolvimento do software. Essas disciplinas são semelhantes as que estudamos anteriormente: - Modelagem de negócios - Requisitos - Analise ou Design - Implementação.

- Teste - Implantação Ainda no RUP, existem 3 disciplinas que servem para suporte e apoio ao ambiente.

- Configuração e Mudanças – Onde acompanha as mudanças, configurações e status/medições, onde são armazenados e que servirão de base para o andamento do projeto.

- Projeto – Abrange questões como gestão de pessoas, orçamento, contratos.

- Ambiente – Atividades que dão suporte à equipe de desenvolvimento, como os itens de IT, servidores, ferramentas.

Essas disciplinas têm suas responsabilidades e funções variadas, dependendo da fase que se encontra o projeto.

No processo RUP o tempo esta dividido em 4 fases.

- Concepção ou Iniciação: Tem como objetivo dar ênfase ao escopo do sistema como um todo.

- Elaboração:Tem como função dar ênfase no design ou arquitetura do produto.

- Construção: Tem como objetivo verificar o andamento do projeto, e suas atividades.

- Transição: Tem como função dar ênfase na implementação do sistema.

Fonte: http://www.wthreex.com/rup/portugues/index.htm EXERCÍCIOS 16.

Qual das funções abaixo NÃO faz parte do Scrum Master? ( ) Responsável por coordenar a reunião diária de andamento do projeto. ( ) Facilitar o dia a dia da equipe, eliminando o que esta atrapalhando no andamento do projeto. ( ) Garantir que as punições impostas à equipe da qual ele chefia, sejam executadas, ( ) Manter a equipe unida pregando os valores do Scrum.

17.

Marque a única alternativa abaixo que não representa uma fase no processo unificado. ( ( ( (

) Elaboração. ) Teste. ) Construção. ) Transição.

SAIBA MAIS Manifesto desenvolvimento ágil de software: http://www.agilemanifesto.org/iso/ptbr/ RUP: http://www.wthreex.com/rup/portugues/index.htm XP: http://pt.wikipedia.org/wiki/Programação_extrema

Resumo de textos sobre processos de desenvolvimento 12

Até começarmos a utilizar Scrum eu nunca havia entendido direito o mecanismo chamado de inspeção e adaptação.

Toda a minha experiência com desenvolvimento de software até então era com utilização de processos cascata em caixinha. Eu chamo de processos em caixinha aqueles processos utilizados em grandes consultorias geralmente mantidos por uma equipe de tamanho razoável que tem como principal responsabilidade escrever e gerenciar diversos templates de documentos. O interessante é que quase nunca as pessoas sabem porque devem preencher esses documentos e na maioria das vezes nem as pessoas que escrevem os templates sabem pra que eles servem.

Nessa época eu sempre me perguntava se era realmente necessário documentar nos mínimos detalhes tudo que era feito dentro do projeto e, quando eu falo de documentar não me refiro somente a artefatos intimamente ligados com código como especificações e modelos, mas também a extensas planilhas de rastreabilidade, longos emails com cópia pra Deus e o mundo entre outros tipos de documentos que completam essa lista.

No final, esses documentos eram todos utilizados pra poder garantir os selos de ISO e CMM que a consultoria buscava ou já mantinha.

No entanto, nunca nenhum desses milhares de documentos que só enchiam o Source Control ajudou alguém em alguma ocasião de problema. Muito pelo contrário: às vezes o cidadão tomava uma bela chamada porque não mantinha os malditos documentos atualizados.

Também pudera, diversos documentos espalhados e sem nenhuma utilidade prática. Quem é que tem paciência de manter atualizado um troço desses?

Em uma dessas empresas que trabalhei, numa determinada época, os desenvolvedores tiveram que estudar a respeito de Six Sigma, pois uma auditoria estava próxima e todos deveriam estar com as respostas prontas na ponta da língua. Foi ai que eu tive o primeiro contato com o mecanismo que intitula este post. Ai foi só ligar as peças.

Todos esses documentos que a equipe gerava deveriam servir como base histórica para consulta a fim de melhorar futuras estimativas e antecipar problemas, ou seja, inspecionar e adaptar!

O problema é que apesar de termos diversos documento e dos mantenedores de processo apostarem suas vidas quando diziam que as metodologias de caixinha utilizavam deste mecanismo, nunca fazíamos nada parecido com uma sprint retrospective, por exemplo. Este é o grande ponto falho de modelos cascata. Como tudo é feito de uma vez, fase a fase, quando percebemos que alguma coisa foi mal (geralmente nas últimas semanas de projeto) já é muito tarde pra correr atrás do problema.

Tudo o que sobra então é procurar quem culpar.

Inspeção e adaptação é um dos mecanismos mais importantes e úteis que você pode utilizar pra melhorar seu trabalho. E é ai que a força dos processos ágeis está. E

não são necessários documentos para isso. Basta comunicação fluente e contínua entre os membros da equipe.

Os processos ágeis são a evolução do modelo cascata. No entanto essa retroalimentação do processo é algo que foi deixada de lado.

Modelos ágeis nos forçam a olhar pra trás freqüentemente para ver onde erramos e onde acertamos. Dentro do Scrum nós temos pelo menos dois momentos para realizar a inspeção e adaptação: Daily Meeting e Sprint Retrospective. Essa primeira reunião executa este processo de maneira menos formal, mas possibilita que todos os membros do time sincronizem seus trabalhos e evitem cometer erros que outros membros já cometeram.

Isso acontece naturalmente na conversa diária de quinze minutos. Já no Sprint Retrospective, que no meu caso acontece de duas em duas semanas, todos estão focados para identificar o que não foi legal e poder corrigir e continuar executando o que estiver dando certo.

Contudo, existe uma coisa que pode prejudicar essa retroalimentação: a incapacidade dos membros do time entenderem que as críticas não são pessoais, mas para críticas as atitudes que levam a falha e ao erro. É importantíssimo que todos no time saibam aceitar quando erraram e procurar melhorar, pois só um time que não deixa de se criticar a cada momento consegue ter pleno sucesso. A crítica é a base para o crescimento.

E funciona porque o processo é executado todo o tempo, e desvios são encontrados quando ainda a tempo de corrigilos. É o puro exercício do aprendizado contínuo!

O processo de Software A utilização de um processo de software têm sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software.

Para poder melhor compreender o assunto é necessário definir o que é um processo de software.

Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. Assim Sommerville[1] trás a seguinte definição: "[O processo é] um conjunto de atividades e resultados associados que produzem um produto de software".

Jalote[7] conclui que um processo de software é : "é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo.

Obviamente , um processo que não aumenta a produção (não suporta projetos de software grandes) ou não pode produzir software com boa qualidade não é um processo adequado."

A partir destas definições podemos considerar que de forma geral um processo de software padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que são utilizadas para construir um 13

produto de software. Na definição de um processo de software devem ser consideradas as seguintes informações: atividades a serem realizadas, recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo de ciclo de vida utilizado [3].

Sucintamente podemos definir o processo de software (defini-lo(o processo) como um conjunto de atividades uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas entradas e produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir um certo objetivo.

Humphrey[4] define as seguintes razões para a definição de um processo padrão: • Redução dos problemas relacionados a treinamento, revisões e suporte às ferramentas; • ?As experiências adquiridas nos projetos são incorporadas ao processo padrão e contribuem para melhorias em todos os processos definidos; • ?Economia de tempo e esforço na definição de novos processos adequados a projetos.

Fases de um processo de Software Para Schwartz[5] as principais fases de um processo de software são : 1. Especificação de Requisitos: tradução da necessidade ou requisito operacional para uma descrição da funcionalidade a ser executada.

2. Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes necessários para codificar o sistema.

3. Programação (Codificação): produção do código que controla o sistema e realiza a computação e lógica envolvida.

4.

Verificação e Integração (Verificação): verificação da satisfação dos requisitos iniciais pelo produto produzido.

Ao contrário do que possa parecer não existe uma seqüência obrigatória de fases, sendo que diversos autores apontam a natureza não-simultânea das fases como uma realidade na aplicação de processos de software, e também defendem que o processo de software é muito mais iterativo e cíclico do que a idéia de fases simples pode sugerir.[6] Atividades do Processo de Software Em cada fase de um processo de software definido são executadas as atividades básicas para que sejam atingidos os objetivos propostos. Segundo Pressman[2] estas atividades constituem um conjunto mínimo para se obter um produto de software.

Realizando uma combinação de classificações dadas por Schwartz[5] , Pressman[2] e Sommerville[1] podemos identificar as seguintes atividades[6]: 1. Especificação 1. Engenharia de Sistema: estabelecimento de uma solução geral para o problema, envolvendo questões extrasoftware.

2. Análise de Requisitos: levantamento das necessidades do software a ser implementado. A Análise tem como objetivo produzir uma especificação de requisitos, que convencionalmente é um documento.

3. Especificação de Sistema: descrição funcional do sistema. Pode incluir um plano de testes para verificar adequação.

2. Projeto 4. Projeto Arquitetural: onde é desenvolvido um modelo conceitual para o sistema, composto de módulos mais ou menos independentes.

5. Projeto de Interface: onde cada módulo tem sua interface de comunicação estudada e definida.

6. Projeto Detalhado: onde os módulos em si são definidos, e possivelmente traduzidos para pseudocódigo.

3. Implementação 7. Codificação: a implementação em si do sistema em uma linguagem de computador.

4. Validação 8. Teste de Unidade e Módulo: a realização de testes para verificar a presença de erros e comportamento adequado ao nível das funções e módulos básicos do sistema.

9. Integração: a reunião dos diferentes módulos em um produto de software homogêneo, e a verificação da interação entre estes quando operando em conjunto.

5. Manutenção e Evolução 10.Nesta fase, o software em geral entra em um ciclo iterativo que abrange todas as fases anteriores.

Desta forma as atividades relacionadas a um processo de software estão diretamente vinculadas com a produção do software como produto final . A fim de especificar quais atividades devem ser executadas e em qual ordem temos diversos modelos de desenvolvimento de software.

Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às situações a analisar, porque só na altura em que enfrentamos o problema é que podemos escolher o modelo.

Nos modelos de processo de software é dado uma atenção especial à representação abstrata dos elementos do processo e sua dinâmica, não estabelecendo métodos de desenvolvimento, pois este trabalha num nível mais alto de abstração do que os modelos de ciclo de vida.WWW[7] A seguir descrevemos os principais modelos : O modelo Cascata Modelo idealizado por Royce em 1970 , também conhecido como abordagem ‘top-down’ , tem como principal característica a seqüência de atividades onde cada fase transcorre completamente e seus produtos são 14

vistos como entrada para uma nova fase. Sofreu diversas ajustes e aprimoramentos sendo muito utilizado nos dias atuais.

Descrição Visual do Modelo

• Os projetos reais raramente se adaptam ao modelo

linear e seqüencial; • É difícil capturar os requisitos de uma só vez; • Cliente tem de pacientemente esperar o resultado final; • Os programadores são freqüentemente atrasados sem necessidade; • Alto custo de correção das especificações quando nas fases de Teste e Implantação.

Modelo Espiral Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando um versão de um software executável.

A idéia principal do modelo é que as diferentes etapas de desenvolvimento seguem uma seqüência, ou seja, a saída da primeira etapa "fluí" para a segunda etapa e a saída da segunda etapa "fluí" para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas seqüencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual.

O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas. Numa tentativa de resolver este tipo de problema foi definido um novo tipo de processo baseado no clássico em cascata, designado por modelo em cascata revisto, cuja principal diferença consiste em prever a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alterações funcionais e/ou técnicas que entretanto tenham surgido, em virtude de um maior conhecimento que entretanto se tenha obtido. O risco desta abordagem é que, na ausência de um processo de gestão do projeto e de controlo das alterações bem definido, podemos passar o tempo num ciclo infinito, sem nunca se atingir o objetivo final, ou seja disponibilizar o sistema a funcionar.[8] As desvantagens deste modelo são : • Dificuldade em acomodar mudanças depois que o processo está a ser executado; • Partição inflexível do projeto em estágios distintos; • Dificuldade em responder a mudanças dos requisitos; • É mais apropriado quando os requisitos são bem compreendidos;

O modelo em espiral foi proposto por Boehm em 1988 como forma de integrar os diversos modelos existentes à época, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses paradigmas.

Entretanto a integração não se dá através da simples incorporação de características dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos.

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos, executa-se 15

uma análise de risco.Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.

Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral, que podem ser: - comunicação com o cliente; - planejamento; - análise de risco; - engenharia; - construção e liberação; - avaliação do cliente.

O modelo espiral é, atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável.

Vantagens deste modelo • modelo em espiral permite que ao longo de cada iteração se obtenham versões do sistema cada vez mais completas, recorrendo à prototipagem para reduzir os riscos.

• Este tipo de modelo permite a abordagem do refinamento seguido pelo modelo em cascata, mas que incorpora um enquadramento iterativo que reflete, de uma forma bastante realística, o processo de desenvolvimento.

Desvantagens • Pode ser difícil convencer grandes clientes ( particularmente em situações de contrato) de que a abordagem evolutiva é controlável.

• A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.

• Este tipo de modelo é relativamente novo e não tem sido amplamente usado.

• É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente alguns aspectos do sistema a ser desenvolvido.

• O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

Modelo de do processo de desenvolvimento iterativo e incremental

Este modelo é uma extensão do modelo espiral sendo porém mais formal e rigoroso.

O desenvolvimento de um produto comercial de software é uma grande tarefa que pode ser estendida por vários meses, possivelmente um ano ou mais.Por isso, é mais prático dividir o trabalho em partes menores ou iterações.Cada iteração resultará num incremento.

Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto.

O princípio subjacente ao processo incremental e iterativo é que a equipa envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e âmbito do sistema envolvido.

Por exemplo, numa primeira iteração deve-se identificar a visão global e determinar a viabilidade econômica do sistema, efetuar a maior parte da análise e um pouco de desenho e implementação. Numa segunda geração, devese concluir a análise, fazer uma parte significativa do desenho e um pouco mais de implementação.

Numa terceira iteração, deve-se concluir o desenho, fazerse parte substancial da implementação, testar e integrar um pouco, etc. Ou seja, a principal conseqüência da aproximação iterativa é que os produtos finais de todo o processo vão sendo amadurecidos e completados ao longo do tempo, mas cada iteração produz sempre um conjunto de produtos finais.

A cada iteração são realizadas as seguintes tarefas: - Análise (refinamento de requisitos, refinamento do modelo conceitual) - Projeto (refinamento do projeto arquitetural, projeto de baixo nível) - Implementação (codificação e testes) -Transição para produto (documentação, instalação, ...)

Vantagens do processo incremental e iterativo - Possibilidade de avaliar mais cedo os riscos e pontos críticos do projeto, e identificar medidas para os eliminar ou controlar; 16

- Redução dos riscos envolvendo custos a um único incremento.Se a equipa que desenvolve o software precisar repetir a iteração, a organização perde somente o esforço mal direcionado de uma iteração, não o valor de um produto inteiro; - Definição de uma arquitetura que melhor possa orientar todo o desenvolvimento; - Disponibilização natural de um conjunto de regras para melhor controlar os inevitáveis pedidos de alterações futuras; - Permite que os vários intervenientes possam trabalhar mais efetivamente pela interação e partilha de comunicação daí resultante; Modelo de Prototipagem O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações do modelo cascata.

De acordo com Jalote[6] a idéia básica deste modelo é que ao invés de manter inalterado os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos. Este desenvolvimento passa por um projeto , codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os requisitos do sistema.

A seqüência de eventos deste modelo esta exibido na figura abaixo:

O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos.

Depois de o protótipo estar pronto o cliente o utiliza e baseado na sua avaliação do cliente é fornecido ao as impressões do que precisa ser alterado, o que esta faltando e o que não é preciso. O protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos. [9] Segundo Pressman e Jalote este modelo pode trazer os seguintes benefícios:

• O modelo é interessante para alguns sistemas de grande

porte nos quais representem um certo grau de dificuldade para exprimir rigorosamente os requisitos • È possível obter uma verão do que será o sistema com um pequeno investimento inicial • A experiência de produzir o protótipo pode reduzir o custo das fases posteriores • A construção do protótipo pode demonstrar a viabilidade do sistema.

Questões a serem consideradas quanto à utilização do modelo: • A Prototipação deve ser utilizada apenas quando os usuários podem participar ativamente no projeto • Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de prototipação • Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente será o mesmo do sistema final • Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos especificados, pois corre-se o risco de ter-se um sistema mal implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções etc) • Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação final Conclusão Não existe um processo correto ou incorreto , como não existe um modelo de desenvolvimento que seja a panacéia universal para o problema do desenvolvimento de software.

Dependendo de sua aplicação , ambiente e objetivo , a utilização de um processo ou modelo específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado e usar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo de desenvolvimento.

References: [1] SOMMERVILLE, I. Software engineering. 5th. ed.

Addison-Wesley, 1995.

[2] PRESSMAN, R. S. , Software engineering: A practitioner's approach. 4th. ed. McGraw-Hill, 1997. p.

22-53.

[3] Falbo, Ricardo A., Integração de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro, Brasil, 1998.

[4] Humphrey, Watts S., Managing the Software Process.

Addison-Wesley Publishing,Company, Massachussets, 1990.

17

[5] SCHWARTZ, J. I. ,Construction of software.

In: Practical Strategies for Developing Large Systems.

Menlo Park: Addison-Wesley, 1st. ed., 1975.

[6] Christian Reis . , Caracterização de um Modelo de Processo para Projetos de Software Livre .teste de mestrado.Instituto de Ciências Matemática e Computação. São Carlos, São Paulo Abril de 2001 WWW[7] http://www.administradores.com.br/colunas_m embro.jsp?idColuna=233&idColunista=555 - Glaucia Gabriel Sass - O Processo de Desenvolvimento Baseado em Componentes: O impulso das novas tecnologias , acessado em 19 de agosto de 2005.

Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de Software (Metodologias Clássicas x Extreme Programming) Este artigo tem como objetivo fazer uma apresentação conceitual sobre uma das mais conhecidas Metodologias Ágeis para Desenvolvimento de Software, a Extreme Programming, apresentando vantagens e desvantagens do uso em relação à Metodologias Clássicas, sejam elas para plataformas Desktop, Web ou Dispositivos Móveis.

Conceitos básicos sobre Metodologias Ágeis para Desenvolvimento de Software (Metodologias Clássicas x Extreme Programming) Este artigo tem como objetivo fazer uma apresentação conceitual sobre uma das mais conhecidas Metodologias Ágeis para Desenvolvimento de Software, a Extreme Programming, apresentando vantagens e desvantagens do uso em relação à Metodologias Clássicas, sejam elas para plataformas Desktop, Web ou Dispositivos Móveis.

1. Metodologias Clássicas (Tradicionais) Também conhecidas como Metodologias orientadas a planejamento, as Metodologias Clássicas dominaram a forma de desenvolvimento de softwares até o início da década de 90, Entretanto, estas metodologias devem ser aplicadas apenas em situações em que os requisitos do sistema são estáveis e os requisitos futuros são previsíveis.

desenvolvimento de software representando entre outros, os métodos Scrum e Extreme Programming (XP), foram estabelecidos princípios e características comuns destes métodos. Assim foi criada a “Aliança Ágil” e efetuou-se o estabelecimento do “Manifesto Ágil”.

2.1 Principais conceitos do Manifesto Ágil: - Pessoas e interações, ao contrário de processos e ferramentas.

- Software executável, ao contrário de documentação extensa e confusa.

- Colaboração do cliente, ao contrário de constantes negociações de contratos.

- Respostas rápidas para as mudanças, ao contrário de seguir planos previamente definidos.

3. Extreme Programming (XP): A Extreme Programming (XP) é uma Metodologia Ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Entre as principais diferenças da XP em relação às Metodologias Clássicas estão o feedback constante, a abordagem incremental e o encorajamento da comunicação entre as pessoas.

A maioria das regras da XP causa surpresa no primeiro contato e muitas não fazem sentido se aplicadas isoladamente. É a força de seu conjunto que sustenta o sucesso da XP, trazendo uma verdadeira revolução no desenvolvimento de software.

O principal objetivo da XP é dar agilidade ao desenvolvimento do projeto e busca garantir a satisfação do cliente. As práticas, regras, e os valores da XP garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos por quatro princípios básicos: A – Princípio da Comunicação - busca manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação.

Metodologias ou Processos orientados a documentação são, de certa forma, barreiras impostas ao desenvolvimento, pois muitas organizações não possuem recursos para processos pesados de produção de software.

Por esta razão, as organizações pequenas acabam por não usar nenhum processo. Isto pode trazer efeitos negativos no que diz respeito a qualidade do produto final, além de dificultar a entrega do software nos prazos, custos e funcionalidades previamente definidas.

2. Metodologias Ágeis e o Manifesto Ágil A expressão “Metodologias Ágeis” tornou-se conhecida em 2001, quando especialistas em processos de 18

B – Princípio da Simplicidade - entende-se como simplicidade, a busca do objetivo de implementar o software com o menor número possível de classes e métodos. Outra idéia importante deste princípio é procurar implementar apenas requisitos atuais, evitando assim adicionar funcionalidades que podem ser importantes apenas no futuro. A aposta da XP é que é melhor fazer algo simples hoje do que implementar algo complicado hoje que talvez não venha a ser usado.

F - Programação em pares - A implementação do código é feita em dupla, ou seja, dois desenvolvedores trabalham em um único computador.

Procurando identificar erros sintáticos e semânticos, pensando estrategicamente em como melhorar o código que está sendo implementado. Esses papéis podem e devem ser

C – Princípio do Feedback - A prática do feedback constante significa que o desenvolvedor terá informações constantes do código e do cliente. A informação do código é dada pelos testes constantes, que indicam os erros tanto individuais quanto do software integrado.

D – Princípio da Coragem - Sabe-se que não são todas as pessoas que possuem facilidade de comunicação e têm bom relacionamento interpessoal, este princípio também dá suporte à simplicidade, pois assim que a oportunidade de simplificar o software é percebida, a equipe pode experimentar e buscar novas soluções, além disso, é preciso coragem para obter e cobrar constantemente um feedback do cliente.

3.1.1 (XP):

Principais práticas da Extreme Programming

A – Planejamento - Define o que é ou não necessário ser feito no projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros.

B - Entregas Freqüentes Baseiam-se no desenvolvimento de um software simples, e conforme os requisitos aparecem, há a atualização da versão do software. Cada versão entregue deve ter o menor tamanho possível, contendo os requisitos de maior valor para o negócio. É recomendado que as versões devam ser entregues a cada mês, ou no máximo a cada dois meses, aumentando a possibilidade de feedback rápido do cliente.

C - Metáfora - São as descrições de um software sem a utilização de termos técnicos com o objetivo de guiar o desenvolvimento do software com a maior transparência possível para o cliente.

D - Projeto simples - O software desenvolvido de acordo com a metodologia XP deve ser o mais simples possível e satisfazer os requisitos atuais, sem a preocupação de requisitos futuros. Eventuais requisitos futuros devem ser adicionados assim que eles realmente existirem.

E – Testes - A Extreme Programming (XP) prioriza a validação do projeto durante todo o processo de desenvolvimento. Os desenvolvedores implementam o software criando primeiramente os testes.

alterados sempre que possível.

G – Refatoração - Focaliza a lapidação do projeto do software e está presente em todas as etapas do desenvolvimento. A refatoração deve ser feita sempre que possível, buscando principalmente simplificar o código atual sem perder nenhuma funcionalidade.

H - Propriedade coletiva - O código do projeto pertence a todos os membros da equipe. Isto significa que qualquer pessoa que percebe que pode adicionar valor a um código, mesmo que ele próprio não o tenha desenvolvido, pode fazê-lo, desde que faça os testes necessários e não prejudique as funcionalidades atuais. Isto é possível porque na XP todos são responsáveis pelo software. Uma grande vantagem desta prática é que, caso um membro da equipe deixe o projeto antes do fim, a equipe consegue continuar o projeto sem grandes dificuldades, pois todos conhecem todas as partes do software, mesmo que não seja de forma detalhada.

I - Integração contínua - É a prática de interagir e construir o sistema de software várias vezes por dia, mantendo os programadores em sintonia, além de possibilitar processos rápidos. Integrar apenas um conjunto de modificações de cada vez é uma prática que funciona bem porque fica óbvio quem deve fazer as correções quando os testes falham. Esta prática é facilitada com o uso de apenas uma máquina de integração, que deve ter livre acesso a todos os membros da equipe.

J - 40 horas de trabalho semanal - a XP assume que não se deve fazer horas extras constantemente. Caso seja necessário trabalhar mais de 40 horas pela segunda semana consecutiva, existe um problema sério no projeto que deve ser resolvido não com aumento de horas trabalhadas, mas com melhor planejamento.

19

K - Cliente presente - É fundamental a participação do cliente durante todo o desenvolvimento do projeto. O cliente deve estar sempre disponível para sanar todas as dúvidas de requisitos, evitando atrasos e até mesmo construções erradas. Uma idéia interessante é manter o cliente como parte integrante da equipe de desenvolvimento (Tester).

L - Código padrão - Baseia-se na padronização da arquitetura do código, para que este possa ser compartilhado entre todos os programadores e até mesmo entre outros softwares.

Scrum Scrum é uma metodologia ágil para gerenciamento de projetos, geralmente de software, mas pode ser utilizada para outros tipos, como desenvolvimento de produtos físicos, ou projetos diversos. Foi criada por Jeff Sutherland, Ken Schwaber e John Scumniotales na década de 1990, baseada no Pensamento Lean (Lean Thinking), desenvolvimento iterativo e incremental, e novas estratégias de criação de produtos. Sua aplicação não está limitada a projetos de software.

O nome foi inspirado numa jogada de Rugby. Após uma "reunião" (agrupamento em torno da bola), o objetivo é retirar os obstáculos à frente do jogador que correrá com a bola, para que possa avançar o máximo possível no campo e marcar pontos.

Processo Básico A partir de uma lista de funcionalidades desejadas para o produto (Product Backlog), priorizada pelo Dono do Produto (Product Owner), o líder do projeto (Scrum Master) escolhe um certo número dessas funcionalidades (Sprint Backlog), que julga-se possível desenvolver num ciclo de 30 dias, chamado Corrida (Sprint). O dia-a-dia desse ciclo contempla algumas atividades características, como a Reunião Em Pé (Standup Meeting) pela manhã, onde cada membro da equipe do projeto deve responder a três perguntas: 1.

O que fez para o projeto desde a última reunião?

2.

O que fará para o projeto até a próxima reunião?

3.

Há algum obstáculo para conseguir seu objetivo?

Precisa de ajuda?

Para acompanhar o progresso e a velocidade da equipe de desenvolvimento, o Scrum utiliza um painel de progresso chamado de Gráfico de Consumo (Burndown Chart), que ilustra a quantidade de funcionalidades que foram desenvolvidas até o momento no Sprint. A inclinação da curva dá a noção de Velocidade (Velocity) da equipe.

Scrum e FDD? Sim, é possível uma convivência pacífica e proveitosa entre a FDD e o Scrum. Lembrando que Scrum é uma metodologia ágil de gerência de projetos, especialmente de produtos, podemos aproveitar o que ela oferece de melhor, como o arcabouço geral do ciclo de vida do produto. Mas Scrum não oferece técnicas para a engenharia do produto, daí a importante colaboração da FDD. Conforme indicado na figura acima, a FDD pode ser praticada em dois momentos: • No início do projeto, para criar o backlog do produto,

através da modelagem abrangente do domínio e construção da lista de features; o planejamento por feature determina a quantidade de Sprints necessários para entregar o produto completo, além da prioridade das features em cada Sprint • Dentro do Sprint, em conjunto com as atividades do

Scrum, como a Reunião Em Pé e o Gráfico de Consumo (o que não exclui o Painel de Monitoramento do Progresso da FDD, que é mais abrangente e adequado para o acompanhamento mais detalhado do projeto).

Para Saber Mais Claro que há muito mais sobre o Scrum, e para saber mais, veja as seguintes fontes: FDD - Feature Driven Development Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) é uma metodologia ágil para gerenciamento e desenvolvimento de software. Ela 20

combina as melhores práticas do gerenciamento ágil de projetos com uma abordagem completa para Engenharia de Software orientada por objetos, conquistando os três principais públicos de um projeto de software: clientes, gerentes e desenvolvedores.

Seus princípios e práticas proporcionam um equilíbrio entre as filosofias tradicionais e as mais extremas, proporcionando uma transição mais suave para organizações mais conservadoras, e a retomada da responsabilidade para as organizações que se desiludiram com as propostas mais radicais.

Processo (WIP - Work In Process). Com menos produtos intermediários temos uma sobrecarga menor no sistema e podemos nos adaptar melhor e mais rápido às mudanças na demanda dos clientes.

Ao limitar o WIP também diminuímos a multitarefa nociva, principal responsável por atrasos, problemas de qualidade, estresse e insatisfação.

Kanban complementa muito bem as abordagens Ágeis, como FDD, Scrum e XP, mas também pode ser usada com métodos tradicionais, inclusive em áreas diferentes de desenvolvimento de software.

O lema da FDD é: "Resultados freqüentes, tangíveis e funcionais."

Saiba mais: • O que é FDD? • Estrutura da FDD • Workshop "FDD Essencial" Participe do grupo público de discussão da FDD. Kanban

Kanban é uma palavra japonesa que significa "sinal visual", comumente interpretada como "cartão" (pois é a forma mais utilizada e conhecida).

Tem sua origem no Sistema Toyota de Produção (TPS - Toyota Production System), cuja tentativa de sistematização, feita por acadêmicos americanos, tornouse conhecida mundialmente como Manufatura Enxuta (Lean Manufacturing).

O uso do Kanban no apoio à Engenharia de Sustentação (e também na Engenharia de Construção) de Software tem crescido rapidamente desde 2003, sendo David Andersonum dos seus principais promotores, com livro a ser lançado no início de 2010, mas já há uma comunidade bem organizada sob o nome de Limited WIP Society.

Kanban é uma das técnicas usadas para implementar o conceito de Produção Puxada (Pull Production), onde a saída de produtos acabados, ao final da linha de montagem, dita o ritmo da introdução de matéria-prima no sistema, evitando acúmulos de produtos inacabados ao longo da linha, diminuindo a quantidade de Trabalho em

exercícios 1) Sobre os processos de teste de software, considere: I. Em um processo de desenvolvimento iterativo, o teste de sistema concentra-se no teste de um incremento que será entregue ao cliente.

II. No teste de integração é feito o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho do sistema torne-se aceitável.

III. A única meta do teste de software é descobrir falhas ou defeitos no software que apresenta comportamento incorreto, não desejável ou em não conformidade com sua especificação.

Está correto o que consta em (A) I, II e III. (B) I e II, apenas.

(C) II e III, apenas.

(D) III, apenas.

(E) I, apenas.

Resposta - E 2) No processo de software é correto afirmar que o modelo Cascata descreve um método de desenvolvimento que é (A) linear e seqüencial e o prazo final é determinado muito tarde no projeto.

(B) linear e seqüencial e o prazo final é determinado muito cedo no projeto.

(C) linear mas não seqüencial e o prazo final é determinado muito tarde no projeto.

(D) iterativo e incremental e o prazo final é determinado muito tarde no projeto.

(E) iterativo e o prazo final é determinado muito cedo no projeto.

Resposta - B 3) No processo de software, a premissa que o desenvolvimento de sistema pode começar com informação incompleta e que requisitos completos são 21

obtidos através de um processo cíclico e dialético de reações do usuário e que o importante nesta abordagem é que o ponto de vista orientado a projeto é enriquecido com o aumento de interesse da participação do usuário final, (A) explica a abordagem bottom-up.

(B) conduz ao caos e à desestruturação do sistema.

(C) é uma definição da engenharia reversa.

(D) define o component-based development.

(E) justifica a abordagem por prototipação.

Resposta - E 4) Uma ferramenta computadorizada de auxílio ao processo de software deve contemplar e permitir seu registro e controle em diversos níveis do ciclo de desenvolvimento: Upper CASE em um nível mais alto e Lower CASE em um nível mais baixo. De acordo com a classificação geralmente aceita, são, respectivamente, duas aplicações coerentes para Upper e duas para Lower: (A) codificação, teste de programa, manutenção e planejamento.

(B) análise, codificação, projeto da aplicação e teste de programa.

(C) análise, planejamento, teste de programa e codificação.

(D) projeto da aplicação, teste de programa, análise e codificação.

(E) planejamento, manutenção, teste de programa e análise.

Resposta - C 5) Os métodos de análise de requisitos de software orientados a objeto possibilitam que o analista modele um problema representando: A) classes, objetos, entidades e operações; B) classes, objetos, entidades e relacionamentos; C) objetos, atributos, entidades e relacionamentos; D) classes, objetos, atributos e relacionamentos; E) classes, objetos, atributos e operações. resposta-E 6) Com relação a projeto e implementação de software, leia com atenção as sentenças abaixo.

I - O projeto de interface estabelece o “layout” e os mecanismos de interação para a interação homem máquina.

II - As atividades de projeto, codificação e teste absorvem 75% ou mais do custo da engenharia de software, excluindo-se a manutenção.

III - O projeto de software pode ser visto de uma perspectiva administrativa composto de atividades de projeto de dados, projeto arquitetural, projeto procedimental e projeto de interfaces.

Pode-se dizer que as sentenças: A) I e II são falsas e a III é verdadeira; B) I e II são verdadeiras e a III é falsa; C) II e III são verdadeiras e a I é falsa; D) II e III são falsas e a I é verdadeira; E) I e III são verdadeiras e a II é falsa. resposta-B 7) O objetivo principal do projeto de casos de teste é derivar um conjunto de testes que tenha uma alta probabilidade de revelar defeitos no software. Dos testes aplicados em projetos de software existem duas categorias diferentes de técnicas de projetos de caso de teste, as quais são: A) teste de caixa branca e teste de comparação; B) teste de caixa preta e teste de laços; C) teste de caixa branca e teste de sistemas de tempo real; D) teste de caixa branca e teste de caixa preta; E) teste de caixa preta e teste de fluxo de dados.

Resposta -D] 8) O modelo adotado pela engenharia de software, originalmente apresentado com iterações distribuídas em quatro quadrantes, onde cada iteração representa versões progressivamente mais completas do software, sendo os quadrantes definidos como Planejamento, Análise dos riscos, Engenharia e Avaliação feita pelo cliente, é, especificamente, o modelo (A) clássico.

(B) por prototipação.

(C)) em espiral.

(D) da análise comportamental.

(E) em cascata. resposta - C 9) Considere as seguintes características: I. Propriedade coletiva.

II. Integração contínua.

III. Metáfora.

Dentre as práticas componentes Programming, aplica-se o que consta em (A) I, apenas.

(B) II, apenas.

(C) I e II, apenas.

(D) II e III, apenas.

(E) I, II e III.

da

Extreme

10) A Feature23. Considere: I. Cada incremento de software é especificado formalmente e essa especificação é transformada em uma implementação.

II. A correção de software é demonstrada por meio de uma abordagem formal.

22

III. Não existe teste de defeitos no processo e o teste do sistema concentra-se na avaliação da confiabilidade.

As três características acima pertencem a um processo formal de desenvolvimento de software, denominado (A) O&M. (B) CMMI. (C) Clean room.

(D) Cobit.

(E) PMI. 11) Considere os requisitos: I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar.

II. O software deve ser processável tanto em alta quanto em baixa plataforma.

III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos.

Exemplo de requisito não funcional consta APENAS em (A) I. (B) II. (C) III. (D) I e II. (E) II e III. 12) Um analista se insere no ambiente de trabalho onde o sistema será usado. Ele observa o trabalho rotineiro e anota as tarefas reais nas quais os participantes estão envolvidos. Trata-se da técnica de elicitação e análise de requisitos denominada (A) Workshop.

(B) Casos de uso.

(C) Validação de requisitos.

(D) Etnografia.

(E) Entrevista.

13). Em se tratando de processo de desenvolvimento de software, é um modelo que utiliza o feedback mais do que o planejamento como seus mecanismos de controle primário para produzir testes regulares e as versões do software desenvolvido. Assim, o seu desenvolvimento prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam levar ao desastre. Trata-se do modelo de processo (A) ágil.

(B) em cascata.

(C) formal.

(D) iterativo.

(E) DSDM.

resposta - D 14). É um processo de desenvolvimento de software que oferece uma forma sistemática para construir um tipo de sistema que usa a arquitetura baseada em componentes; pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo; define tanto métodos para controlar e monitorar mudanças quanto áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas em outro sistema não afetarão o seu sistema. Trata-se do processo (A) DSDM. (B) XP. (C) TDP. (D) DDP. (E) RUP. RESPOSTA - E 15) XP (eXtreme Programming) é uma metodologia ágil para equipes pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança.

Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática é denominada (A) Refatoração.

(B) Integração Contínua.

(C) Desenvolvimento Orientado a Testes.

(D) Ritmo Sustentável.

(E) Time Coeso.

RESPOSTA - B 16). A Feature Driven Development (FDD) é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto afirmar: (A) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e Implementar por Funcionalidade.

(B) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada categoria, os papéis são atribuídos a um único participante que assume a responsabilidade pelo papel.

(C) Mantém seu foco apenas na fase de modelagem.

(D) Mantém seu foco apenas na fase de implementação.

(E) Não pode ser combinada a outras técnicas para a produção de sistemas.

Resposta - A 23

17) A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos cartões que são conhecidos como (A) cartões de planejamento.

(B) cartões chave.

(C) cartões inteligentes.

(D) histórias de usuário.

(E) cartões de requisitos.

Resposta - D 18) Na fase de desenvolvimento do Scrum, o software é desenvolvido em processos iterativos denominados (A) Product Backlog.

(B) Sprint.

(C) Product Owner.

(D) Product Backlog Cycle.

(E) Building Products.

RESPOSTA - B 19) O modelo adotado pela engenharia de software, originalmente apresentado com iterações distribuídas em quatro quadrantes, onde cada iteração representa versões progressivamente mais completas do software, sendo os quadrantes definidos como Planejamento, Análise dos riscos, Engenharia e Avaliação feita pelo cliente, é, especificamente, o modelo (A) clássico.

(B) por prototipação.

(C)) em espiral.

(D) da análise comportamental.

(E) em cascata.

RESPOSTA - C 20) São três práticas da Extreme Programming (XP): (A) Cliente junto aos desenvolvedores, propriedade individual e semana livre.

(B) Fases extensas, propriedade individual e testes.

(C) Programação individual bem definida, semana livre e dispensa de testes.

(D) Design complexo, programação em pares e propriedade individual.

(E)) Propriedade coletiva, programação em pares e semana de 40 horas (5 dias, 8 horas por dia).

REPOSTA - E 21).São quatro fases do RUP:

(A) Transaction, Implementation, Requirements e Configuration.

(B) Project Management, Transaction, Construction e Interaction.

(C) Deployment, Transition, Design e Requirements.

(D)) Inception, Construction, Elaboration e Transition.

(E) Analysis, Design, Elaboration e Inception.

RESPOSTA - D 22) Com relação às metodologias de desenvolvimento de software, é correto afirmar que o (A) Waterfall é um modelo iterativo que incentiva o feedback em cada fase.

(B) modelo V-Shaped permite a codificação de artefatos de software nas primeiras fases do desenvolvimento.

(C) modelo Espiral é composto pelas fases de Requisitos de Usuário, Requisitos de Software, Design Arquitetural, Codificação, Teste e Operação.

(D) processo unificado (UP) é iterativo e incremental, composto pelas fases de Concepção, Elaboração, Codificação e Transição.

(E) Extreme Programming (XP) é utilizado em projetos de software onde há programação em pares e não existe um gerente de projetos RESPOSTA C 23) Com relação a teste de software, é correto afirmar que: (A) Teste de Stress tem caráter destrutivo, sendo utilizado para definir os valores máximos de carga que a aplicação suporta.

(B) Ferramentas de acompanhamento de erros (bug tracking) são utilizadas para automatizar testes de performance.

(C) Teste Unitário é utilizado para validar as interfaces entre os componentes e é baseado no grafo de chamadas entre estes componentes.

(D) Teste de Sistema é utilizado para análise do fluxo de dados e de controle, sendo normalmente automatizado por ferramentas xUnit como JUnit e CppUnit.

(E) Teste Estrutural é utilizado para medir o Comportamento da aplicação em função de seus recursos e da carga gerada por um gerador de transações.

RESPOSTA - A 24). Observe a seguinte definição: “Um processo dinâmico e interativo para determinação de objetivos, políticas e estratégias (atuais e futuras) das funções empresariais e dos procedimentos de uma organização.

Elaborado por meio de técnicas administrativas de análise do ambiente (interno e externo), das ameaças e oportunidades, dos seus pontos fortes e fracos, que 24

possibilita os gestores estabelecerem um rumo para a organização, buscando um certo nível de otimização no relacionamento entre empresa, ambiente e mercado.

Formalizado para produzir e articular resultados, na forma de integração sinergética de decisões e ações organizacionais.” É coerente com esta definição (A) o Planejamento das Informações.

(B) a Gerência de Projetos.

(C) a Gerência de Escopo do Projeto.

(D) o Planejamento de Infra-estrutura Tecnológica.

(E)) o Planejamento Estratégico Empresarial.

RESPOSTA - E 25)

28) Não se adéqua ao conjunto de tarefas para planejamento de projeto (A) a definição dos recursos reusáveis de software.

(B) a execução de testes de alta prioridade.

(C) o estabelecimento do escopo do projeto.

(D) a determinação dos recursos humanos necessários.

(E) a determinação da viabilidade do projeto.

REPOST0A - B 29) Via de regra as divisões da arquitetura de software em três camadas orientam para níveis que especificam (A) os casos de uso, a estrutura dos dados e os processos de manutenção.

(B) a apresentação, as regras de negócio e os testes.

(C) a apresentação, os processos operacionais e a seqüência de execução.

(D) a apresentação, os componentes virtuais e a seqüência de execução.

(E) a apresentação, as regras de negócio e o armazenamento de dados.

RESPOSTA - E

Resposta A 26) O objetivo principal do projeto de casos de teste é derivar um conjunto de testes que tenha uma alta probabilidade de revelar defeitos no software. Dos testes aplicados em projetos de software existem duas categorias diferentes de técnicas de projetos de caso de teste, as quais são: A) teste de caixa branca e teste de comparação; B) teste de caixa preta e teste de laços; C) teste de caixa branca e teste de sistemas de tempo real; D) teste de caixa branca e teste de caixa preta; E) teste de caixa preta e teste de fluxo de dados.

RESPSOTA - D 27) No RUP, desde a concepção do sistema é definido um padrão de construção dos componentes que, inicialmente, visa elaborar, (A) o diagrama de Objetos.

(B) a estrutura de negócios.

(C) a estrutura física do banco de dados.

(D) o projeto lógico do banco de dados.

(E) a arquitetura candidata.

30) Driven Development (FDD) é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto afirmar: (A) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e Implementar por Funcionalidade.

(B) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada categoria, os papéis são atribuídos a um único participante que assume a responsabilidade pelo papel.

(C) Mantém seu foco apenas na fase de modelagem.

(D) Mantém seu foco apenas na fase de implementação.

(E) Não pode ser combinada a outras técnicas para a produção de sistemas.

RESPOSTA - A 31). A Extreme Programming (XP) baseia-se em 12 práticas, que são um conjunto de atividades que deverão ser seguidas pelas equipes que desejam utilizar a XP. Na prática do Jogo do Planejamento, as funcionalidades são descritas em pequenos cartões que são conhecidos como (A) cartões de planejamento.

(B) cartões chave.

(C) cartões inteligentes.

(D) histórias de usuário.

(E) cartões de requisitos . RESPOSTA – D

RESPOSTA - E 25

32) Na fase de desenvolvimento do Scrum, o software é desenvolvido em processos iterativos denominados (A) Product Backlog.

(B) Sprint.

(C) Product Owner.

(D) Product Backlog Cycle.

(E) Building Products.

(C) modelo Espiral é composto pelas fases de Requisitos de Usuário, Requisitos de Software, Design Arquitetural, Codificação, Teste e Operação.

(D) processo unificado (UP) é iterativo e incremental, composto pelas fases de Concepção, Elaboração , Codificação e Transição.

(E) Extreme Programming (XP) é utilizado em projetos de software onde há programação em pares e não existe um gerente de projetos.

RESPOSTA - B 33) São três práticas da Extreme Programming (XP): (A) Cliente junto aos desenvolvedores, propriedade individual e semana livre.

(B) Fases extensas, propriedade individual e testes.

(C) Programação individual bem definida, semana livre e dispensa de testes.

(D) Design complexo, programação em pares e propriedade individual.

(E)) Propriedade coletiva, programação em pares e semana de 40 horas (5 dias, 8 horas por dia).

RESPOSTA - E 34. São quatro fases do RUP: (A) Transaction, Implementation, Requirements e Configuration.

(B) Project Management, Transaction, Construction e Interaction.

(C) Deployment, Transition, Design e Requirements.

(D)) Inception, Construction, Elaboration e Transition.

(E) Analysis, Design, Elaboration e Inception.

RESPOSTA - D 35) O modelo adotado pela engenharia de software, originalmente apresentado com iterações distribuídas em quatro quadrantes, onde cada iteração representa versões progressivamente mais completas do software, sendo os quadrantes definidos como Planejamento, Análise dos riscos, Engenharia e Avaliação feita pelo cliente, é, especificamente, o modelo (A) clássico.

(B) por prototipação.

(C)) em espiral.

(D) da análise comportamental.

(E) em cascata.

resposta - D 37) No RUP, a maior porção do Core Process Workflow, denominado Analysis & Design, é executada na Phase (A) Elaboration.

(B) Construction.

(C) Requirements.

(D) Inception.

(E) Deployment.

REP0STA – A 38) No RUP, a análise do domínio do problema, o desenvolvimento do plano do projeto, o estabelecimento de uma sólida base arquitetural e a eliminação dos elementos de mais alto risco do projeto são objetivos (A) da Elaboration Phase.

(B) da Construction Phase.

(C) da Inception Phase.

(D) da Transition Phase.

(E) do Deployment.

RESPOSTA - A 39). Em uma das fases do RUP encontra-se o terceiro maior milestone do projeto onde é decidido se o software, os sites e os usuários estão operacionalmente prontos, sem expor o projeto a altos riscos. Freqüentemente chamado de “beta” release é o (A) Initial Product Release Milestone no final da Elaboration Phase.

(B) Product Release Milestone no final da Construction Phase.

(C) Initial Operational Capability Milestone no final da Construction Phase.

(D) Initial Operational Capability Milestone no final da Transition Phase.

(E) Product Release Milestone no início da Construction Phase.

RESPOSTA - C RESPOSTA – C 36). Com relação às metodologias de desenvolvimento de software, é correto afirmar que o (A) Waterfall é um modelo iterativo que incentiva o feedback em cada fase.

(B) modelo V-Shaped permite a codificação de artefatos de software nas primeiras fases do desenvolvimento.

40) Na plataforma de desenvolvimento RUP orientado a serviços Web, a "criação do modelo de negócioAs-Is" e o "gerenciamento de projetos e recursos" são contidos, respectivamente, em (A) WebSphere Business Modeler e Rational Portfolio Manager.

26

(B) WebSphere Business Modeler e WebSphere Integration Developer.

(C) Rational Portfolio Manager e WebSphere Integration Developer.

(D) Rational Portfolio Manager e WebSphere Business Modeler.

(E) WebSphere Business Modeler e Rational Portfolio Manager.

41) São produtos da fase de elaboração do RUP: (A) documento de visão e produto de software integrado.

(B) descrição da arquitetura do software e lista de riscos revisada.

(C) manual do usuário e base de dados operacionais convertidas.

(D) lista de riscos revisada e base de dados operacionais convertidas.

(E) produto de software integrado e descrição da arquitetura do software.

42). NÃO é um dos Core Process Workflows do RUP o (A) Implementation.

(B) Environment.

(C) Test.

(D) Requirements.

(E) Deployment.

RESPOSTA – B 43) No RUP, desde a concepção do sistema é definido um padrão de construção dos componentes que, inicialmente, visa elaborar, (A) o diagrama de Objetos.

(B) a estrutura de negócios.

(C) a estrutura física do banco de dados.

(D) o projeto lógico do banco de dados.

(E) a arquitetura candidata. resposta - E 44) Dos nove core process workflow do RUP, são, respectivamente, dois core engineering e dois core supporting workflows: (A) Implementation, Test, Project Management e Environment.

(B) Requirements, Configuration and Change Management, Project Management e Test.

(C) Configuration and Change Management, Implementation, Requirements e Test.

(D) Project Management, Business modeling, Requirements e Implementation.

(E) Business modeling, Requirements, Analysis & Design e Implementation.

resposta - A 45) A maior porção da Configuration & Change Management do RUP encontra-se nas fases ( A) Inception e Elaboration. ( B) Elaboration e Transition.

(C) Elaboration e Construction. ( D) Construction e Transition.

(E) Inception e Construction. resposta - D 46) A Organization along content do RUP está estruturada em (A) Core Process Workflows e Phases, somente.

(B) Phases e Iterations, somente.

(C) Core Process Workflows, Core Supporting Workflows, Phases e Iterations.

(D) Core Process Workflows, Core Supporting Workflows e Phases, somente.

(E) Core Process Workflows e Core Supporting Workflows, somente.

Resposta - E 47)O RUP possibilita o desenvolvimento (A) incremental e interativo, guiado por casos de uso e centrado na arquitetura do sistema.

(B) interativo e centrado nos dados e informações do sistema.

(C) incremental e interativo, em quatro camadas e centrado na estrutura dos dados do sistema.

(D) interativo, guiado por casos de uso e centrado na infra-estrutura do sistema.

(E) incremental e centrado na funcionalidade do sistema. resposta– A 48) De acordo com o RUP, balancear objetivos, administrar riscos e superar restrições para entregar um produto que atenda às necessidades de clientes e usuários é papel do (A) Gerente de Projetos.

(B) Analista de Sistemas.

(C) Administrador de Dados.

(D) Analista de Requisitos.

(E) Arquiteto de Software.

Resposta - A 49) Em se tratando de processo de desenvolvimento de software, é um modelo que utiliza o feedback mais do que o planejamento como seus mecanismos de controle primário para produzir testes regulares e as versões do software desenvolvido. Assim, o seu desenvolvimento 27

prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam levar ao desastre. Trata-se do modelo de processo (A) ágil.

(B) em cascata.

(C) formal.

(D) iterativo.

(E) DSDM. resposta - D 50) É um processo de desenvolvimento de software que oferece uma forma sistemática para construir um tipo de sistema que usa a arquitetura baseada em componentes; pode ser facilmente extensível, promovendo a reutilização de software e um entendimento intuitivo; define tanto métodos para controlar e monitorar mudanças quanto áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas em outro sistema não afetarão o seu sistema. Trata-se do processo (A) DSDM. (B) XP. (C) TDP. (D) DDP. (E) RUP. resposta - E 51). XP (eXtreme Programming) é uma metodologia ágil para equipes pequenas e médias que desenvolverão software com requisitos vagos e em constante mudança.

Para isso, adota a estratégia de constante acompanhamento e realização de vários pequenos ajustes durante o desenvolvimento de software. Para aplicar os valores e princípios durante o desenvolvimento de software, a XP propõe uma série de práticas, sendo uma delas: sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema a fim de evitar o aumento da possibilidade de conflitos e da possibilidade de erros no código fonte. Tal prática é denominada

(A) I, apenas.

(B) II, apenas.

(C) I e II, apenas.

(D) II e III, apenas.

(E) I, II e III. resposta - E 53) No processo de software é correto afirmar que o modelo Cascata descreve um método de desenvolvimento que é (A) linear e seqüencial e o prazo final é determinado muito tarde no projeto.

(B) linear e seqüencial e o prazo final é determinado muito cedo no projeto.

(C) linear mas não seqüencial e o prazo final é determinado muito tarde no projeto.

(D) iterativo e incremental e o prazo final é determinado muito tarde no projeto.

(E) iterativo e o prazo final é determinado muito cedo no projeto. resposta - B 54) No processo de software, a premissa que o desenvolvimento de sistema pode começar com informação incompleta e que requisitos completos são obtidos através de um processo cíclico e dialético de reações do usuário e que o importante nesta abordagem é que o ponto de vista orientado a projeto é enriquecido com o aumento de interesse da participação do usuário final, (A) explica a abordagem bottom-up.

(B) conduz ao caos e à desestruturação do sistema.

(C) é uma definição da engenharia reversa.

(D) define o component-based development.

(E) justifica a abordagem por prototipação. resposta - E

(A) Refatoração.

(B) Integração Contínua.

(C) Desenvolvimento Orientado a Testes.

(D) Ritmo Sustentável.

(E) Time Coeso.

55) No RUP, a maior porção do Core Process Workflow, denominado Analysis & Design, é executada na Phase (A) Elaboration.

(B) Construction.

(C) Requirements.

(D) Inception.

(E) Deployment.

resposta - B

resposta - A

52) Considere as seguintes características: I. Propriedade coletiva.

II. Integração contínua.

III. Metáfora.

Dentre as práticas componentes da Programming, aplica-se o que consta em

56) Em uma das fases do RUP encontra-se o terceiro maior milestone do projeto onde é decidido se o software, os sites e os usuários estão operacionalmente prontos, sem expor o projeto a altos riscos. Freqüentemente chamado de “beta” release é o (A) Initial Product Release Milestone no final da Elaboration Phase.

Extreme

28

(B) Product Release Milestone no final da Construction Phase.

(C) Initial Operational Capability Milestone no final da Construction Phase.

(D) Initial Operational Capability Milestone no final da Transition Phase.

(E) Product Release Milestone no início da Construction Phase.

Resposta - C 57) São produtos da fase de elaboração do RUP: (A) documento de visão e produto de software integrado.

(B) descrição da arquitetura do software e lista de riscos revisada.

(C) manual do usuário e base de dados operacionais convertidas.

(D) lista de riscos revisada e base de dados operacionais convertidas.

(E) produto de software integrado e descrição da arquitetura do software.

"gerenciamento de projetos e recursos" são contidos, respectivamente, em (A) WebSphere Business Modeler e Rational Portfolio Manager.

(B) WebSphere Business Modeler e WebSphere Integration Developer.

(C) Rational Portfolio Manager e WebSphere Integration Developer.

(D) Rational Portfolio Manager e WebSphere Business Modeler.

(E) WebSphere Business Modeler e Rational Portfolio Manager.a reposta - A 61)

resposta - B 58) Considere: I. Desenvolvimento de um modelo geral.

II. Construção da lista de funcionalidades.

III. Plano de liberações com base nas funcionalidades a implementar.

IV. Projetar com base nas funcionalidades.

V. Implementar com base nas funcionalidades.

São fases de projetos que seguem o processo projetado por Peter Coad, Erich Lefebvre e Jeff De Luca chamado De (A) MDA (B) XP (C) FDD (D) RUP (E) MVC

Resposta E 61)

resposta - C 59) No RUP, o maior volume de testes ocorre, específica e ordenadamente, entre as fases de (A) Transition e Inception.

(B) Construction e Transition.

(C) Construction e Inception.

(D) Elaboration e Construction.

(E) Inception e Elaboration. resposta - B 60) Na plataforma de desenvolvimento RUP orientado a serviços Web, a "criação do modelo de negócio As-Is" e o

Resposta e

62) O RUP (Rational Unified Process) é um processo iterativo de desenvolvimento de software, baseado no Processo Unificado. A esse respeito, analise as afirmativas a seguir.

29

I - Um dos objetivos da fase de Elaboração é a criação e estabilização da arquitetura do sistema.

II - São exemplos de disciplinas do RUP: Modelagem de Negócio, Gestão de Portifólios e Gestão da Documentação Técnica.

III - O principal artefato de requisitos utilizado pelo RUP é a Estória de Usuário (User Story), que serve como um “lembrete” para uma conversa sobre os requisitos entre o desenvolvedor e o cliente.

IV - Um dos princípios do RUP é considerar como medida principal do progresso do projeto o software executável funcionando.

Estão corretas APENAS as afirmativas (A) I e II (B) I e IV (C) II e III (D) II e IV (E) III e IV Resposta b 63)

II - O gráfico deixa claro que o maior investimento na prevenção de defeitos deve acontecer nas fases finais do projeto, preferencialmente depois que o software estiver em uso pelos clientes.

III - O gráfico não é conclusivo a respeito da importância do gerenciamento dos requisitos de um projeto, o que é consistente com a abordagem de muitos processos de desenvolvimento de software atuais, que minimizam este esforço e enfatizam a codificação e os testes unitários de código.

IV - O gráfico sustenta os argumentos de que a qualidade deve ser incorporada ao processo através de técnicas e ações efetivas de detecção, prevenção e controle, garantindo que todas as atividades do projeto resultem em produtos ou subprodutos de qualidade, ao invés de ser uma preocupação secundária ou limitada a um grupo de profissionais de controle de qualidade.

São corretas APENAS as afirmativas (A)

I e II

(B) I e IV (C) II e III (D) II e IV (E) III e IV Reposta b 64) Considere: I. Cada incremento de software é especificado formalmente e essa especificação é transformada em uma implementação.

II. A correção de software é demonstrada por meio de uma abordagem formal.

III. Não existe teste de defeitos no processo e o teste do sistema concentra-se na avaliação da confiabilidade.

O gráfico acima, adaptado do livro Engenharia de Software, de Roger Pressman, ilustra o custo relativo da correção de um defeito nas diversas fases de um projeto de software, baseado em dados colhidos por Boehm e outros estudiosos. Embora não seja explicitamente informado, os dados se basearam, principalmente, em projetos que utilizaram o modelo de desenvolvimento em cascata. A esse respeito, analise as afirmativas a seguir.

I - O gráfico pode ser utilizado como um argumento a favor do uso de processos de desenvolvimento iterativos.

As três características acima pertencem a um processo formal de desenvolvimento de software, denominado (A) O&M. (B) CMMI. (C) Clean room.

(D) Cobit.

(E) PMI. Resposta - C 65) Considere os requisitos: 30

I. Os valores das faturas devem ser totalizados por cliente e por data de vencimento igual à fornecida pela área de contas a pagar.

II. O software deve ser processável tanto em alta quanto em baixa plataforma.

III. A data de vencimento constante dos boletos de pagamento deve ser igual à data de registro de entrada do documento no cadastro, mais 30 dias corridos.

Exemplo de requisito não funcional consta APENAS em (A) I. (B) II. (C) III. (D) I e II. (E) II e III. Resposta – B 66) Um analista se insere no ambiente de trabalho onde o sistema será usado. Ele observa o trabalho rotineiro e anota as tarefas reais nas quais os participantes estão envolvidos. Trata-se da técnica de elicitação e análise de requisitos denominada

Resposta - E 69) Como várias pessoas trabalham em paralelo e concorrentemente nos mesmos arquivos do projeto, é necessária uma política para ordenar e integrar todas essas fontes de alterações, de modo a evitar que uma pessoa sobrescreva o trabalho de outra. No controle de mudanças de software, a frase acima (A) está coerente e diz respeito à sincronização de mudanças concorrentes.

(B) se baseia em uma premissa não recomendada que seja ter várias pessoas trabalhando concorrentemente.

(C) se baseia em uma necessidade real, porém a política de ordenar e integrar não são recomendados.

(D) não está totalmente correta porque quando relaciona a política de ordenação e integração ao fato “evitar que uma pessoa sobrescreva o trabalho de outra”, entra no campo do impraticável.

(E) está coerente e diz respeito à proibição de mudanças concorrentes.

Resposta - A

(A) Workshop.

(B) Casos de uso.

(C) Validação de requisitos.

(D) Etnografia.

(E) Entrevista.

Resposta – D 67) Freqüentemente usado para modelagem de sistemas de tempo real. Descreve como um sistema responde aos estímulos internos e externos. Mostra as diferentes situações do sistema e os estímulos que provocam transições de uma para outra situação. Trata-se do modelo de (A) eventos.

(B) agregação de objetos.

(C) dados.

(D) fluxo de dados.

(E) máquina de estado.

70) Com relação a projeto e implementação de software, leia com atenção as sentenças abaixo.

I O projeto de interface estabelece o “layout” e os mecanismos de interação para a interação homem máquina.

II As atividades de projeto, codificação e teste absorvem 75% ou mais do custo da engenharia de software, excluindo-se a manutenção.

III O projeto de software pode ser visto de uma perspectiva administrativa composto de atividades de projeto de dados, projeto arquitetural, projeto procedimental e projeto de interfaces.

Pode-se dizer que as sentenças: A) I e II são falsas e a III é verdadeira; B) I e II são verdadeiras e a III é falsa; C) II e III são verdadeiras e a I é falsa; D) II e III são falsas e a I é verdadeira; E) I e III são verdadeiras e a II é falsa.

Resposta - E Resposta-B 68) Associadas à especificação de sistemas críticos, as técnicas de decomposição de riscos podem ser (1) dedutivas - do risco em direção à falha possível ou indutiva da falha proposta em direção aos possíveis perigos que levar-na-iam a ocorrer, ou seja, respectivamente, técnicas (A) bottom-down e bottom-up.

(B) bottom-up e top-down.

(C) top-up e top-down.

(D) top-down e top-up.

(E) top-down e bottom-up.

71) O método de modelagem de requisitos que utiliza diagramas de fluxo de dados e de controle como base, divide em partições as funções que transformam os fluxos, cria um modelo comportamental utilizando o diagrama de transição de estados e um modelo de conteúdo de dados através de um dicionário de requisitos, em que o sistema é representado como uma transformação de informação, sendo sua função global representada por uma bolha, é a análise: A) comportamental; 31

B) dos requisitos; C) orientada a objetos; D) de tempo real; E) estruturada.

Resposta-E 72) A ferramenta usada para representar o comportamento tempo-dependente, característica importante em sistemas que produzem respostas e dados de saída com grande rapidez para interagir com o ambiente externo, é o (A) Diagrama de Transição de Estado.

(B) Diagrama Hierárquico.

(C) Dicionário de Dados.

(D) Diagrama de Contexto.

(E) Fluxograma.

Resposta – A 73) As necessidades de informação automatizadas devem ser expressas, principalmente, na forma de requisitos (A) funcionais, somente.

(B) de qualidade, somente.

(C) de segurança, somente.

(D) de hardware e software, somente.

(E)) funcionais e não funcionais.

Resposta - E

antecipar a codificação e teste das funcionalidades de maior risco, é mais recomendável que (A) seja utilizado o ciclo em cascata.

(B) a análise de requisitos seja feita no final do projeto.

(C) seja utilizado o ciclo iterativo e incremental.

(D) se desenvolva o projeto de modo reverso ao do ciclo em cascata.

(E) o levantamento de requisitos seja postergado para após a fase de construção do código.

Resposta - C 77) Segundo a dimensão X o objetivo do processo de requisitos é levar de um entendimento vago e esparso do sistema, em sua fase inicial, a um entendimento completo e detalhado no final do processo. A dimensão Y objetiva expressar o conhecimento adquirido sobre o sistema durante o processo de requisitos e leva de descrições informais a descrições formais. Segundo a dimensão Z, o processo de requisitos visa levar os stakeholders de sua percepção individual sobre os requisitos a uma visão única e que reflita o acordo a que chegaram durante o processo de requisitos. As três dimensões X, Y e Z mencionadas no texto conceituam, respectivamente, (A) interoperabilidade, representação e concepção.

(B) domínio, funcionalidade e testabilidade.

(C) graduação, domínio e conectividade.

(D) especificação, representação e consenso.

(E) conectividade, estabilidade e especialização

74) NÃO é um item que deve compor uma arquitetura de informações da empresa:

Resposta - D

(A)) metodologia de desenvolvimento de sistemas.

(B) processos funcionais.

(C) áreas organizacionais.

(D) sistemas de informação.

(E) dicionário de dados corporativos.

78) Define uma técnica para especificação de sistemas separando-os em duas visões: a da funcionalidade (plataforma independente) e a da implementação (Plataforma específica)

Resposta - A 75) No processo de desenvolvimento de sistemas, NÃO se trata de uma técnica de coleta de dados, (A) as visitas às instalações usuárias.

(B) as entrevistas realizadas.

(C) os questionários aplicados.

(D) as apresentações dos fornecedores.

(E)) as análises do sistema atual.

Resposta - E 76) No ciclo de vida do projeto considera-se que os riscos técnicos são mitigados, na prática, quando se implementa e testa o código relacionado ao risco. Em virtude de

(A) o Control Objectives for Information and related Technology.

(B) A Extreming Programming.

(C) O Rational Unified Process.

(D) A Model Driven Architecture.

(E) A Information Technology Infrastructure Library.

Resposta - D 79) Inicialmente os stakeholders participam ativamente da fase de especificação de requisitos descrevendo as ações do sistema e os agentes que com elas interagem usando o modelo UML (A) de Objetos.

(B) de Classes.

(C) Funcional.

(D) de Casos de Uso. 32

(E) de Máquina de Estados.

(E) codificação de software.

Resposta - D

Resposta - C

80) Para responder a considere o diagrama abaixo.

83) As avaliações de funcionalidade e de desempenho dos programas de um sistema submetidos a situações anormais tratam-se de teste de (A)) estresse.

(B) recuperação.

(C) segurança.

(D) caixa preta.

(E) caixa branca.

Resposta - A

Supondo que as três camadas verticais do diagrama sejam aplicadas a um modelo MVC e que X represente à camada de apresentação e Z a camada de negócios, é correto afirmar que X, Y e Z correspondem, respectivamente, a (A) Controlador, Visão e Modelo.

(B) Controlador, Modelo e Visão.

(C) Modelo, Visão e Controlador.

(D) Visão, Modelo e Controlador.

(E) Visão, Controlador e Modelo.

Resposta- E 81) Para responder a considere o diagrama abaixo.

Supondo que as três camadas verticais do diagrama sejam aplicadas a um modelo MVC (versão Modelo um) e considerando duas regras básicas de interação, é correto afirmar que os componentes representados nas camadas se comunicam da seguinte forma: (A) Z despacha as solicitações para Y e Y observa X. (B) Y despacha as solicitações para X e Z observa X. (C) Y despacha as solicitações para Z e X observa Z. (D) Z despacha as solicitações para Y e Z observa X. (E) X despacha as solicitações para Z e Z observa X. Resposta– A 82) O primeiro passo técnico do processo de engenharia de software é a etapa de (A) planejamento do projeto de software.

(B) testes de programas.

(C)) análise de requisitos.

(D) projeto de software.

Atenção: Para responder as questões de números 84 a 95, considere o texto abaixo.

Objetivos e requisitos de modernização de processos e de TI em órgão jurídico da esfera governamental Um determinado órgão jurídico da área governamental decide implantar um sistema eletrônico de atendimento ao cidadão, via Web, que visa fornecer informações para os interessados a respeito da situação de processos de seu interesse. Nesse sentido, os interessados deverão realizar um pré-cadastro na página e aguardar retorno no e-mail informado para confirmar inscrição. A consulta pode ser feita pelo número do processo, por palavra-chave, assunto ou data de ingresso e deve ser orientada à facilidade de acesso de todos os cidadãos, indistintamente, considerando, principalmente, aquele feito por pessoas com necessidades especiais. Para atingir esse objetivo um outro sistema de cadastramento de processos deve ser desenvolvido para gerenciar e controlar otrâmite (inclusive entre órgãos) desde o início até a conclusão de cada processo, registrando os pareceres, responsáveis, áreas, etc..

Para iniciar cada processo, o funcionário registra os dados de identificação do interessado, o objetivo do processo, a área a que corresponde e demais dados de interesse. O processo deve receber uma numeração e ser encaminhado para a primeira instância de análise para que seja dado o recebimento e o primeiro parecer e depois seguir com os demais encaminhamentos, até sua solução e arquivamento.

O uso de ferramentas de apoio à decisão, a gestão da documentação, a governança e integração em TI também são requisitos da direção do órgão, visando à racionalização e modernização de processos. Isto quer dizer que estudos de viabilidade, análise, implementação e implantação de ambiente ERP, de aplicativos de GED, de processo de Data Warehousing, bem como outros a serem pesquisados são fundamentais.

Previamente às questões de TI, deve ser feito um mapeamento de processos de negócio e uma análise crítica dos procedimentos, fluxos e atividades realizadas visando à proposição de modelos mais vantajosos, 33

respaldados na simplificação e racionalização de processos, com conseqüente redução de recursos, prazos e custos envolvidos.

Um diagnóstico da situação atual do órgão indica a necessidade de amadurecimento do processo de software, estando, entretanto, como um todo, classificado um nível acima do Inicial do Capability Maturity Model.

A qualidade dos sistemas de informação, a segurança ambiental de TI, a segurança e sigilo dos dados para evitar acesso não autorizado, intrusão e/ou manipulação, bem como a recuperação em caso de falhas, perdas ou danos às informações são requisitos essenciais de negócio.

Outros fatores fundamentais são o planejamento e o controle da execução do projeto na razão dos riscos, custos, recursos e prazos que devem ser rigorosamente acompanhados em função do orçamento governamental.

84) No texto apresentado, o uso de um modelo AS-IS é especificamente subentendido quando (A) recomendado o planejamento e o controle do projeto.

(B) recomendada à segurança ambiental de TI. (C) especificada a necessidade de mapeamento dos processos de negócio.

(D) requisitada à implantação de aplicativos de GED. (E) especificada a implantação de processo de Data Warehousing.

Reposta - C 85) Supondo que a classe Processo especificada possua um atributo chamado parecer que é, na realidade, a representação da classe Parecer. Em UML este tipo de associação entre classes é definido como um relacionamento de (A) dependência.

(B) extensão.

(C) composição.

(D) generalização.

(E) agregação simples Resposta – A 86) Observe a especificação da necessidade de proposição de modelos de processos de negócio mais vantajosos em relação aos atualmente em uso. Os novos processos serão representados em um modelo (A) RUP (B) XP (C) MVC (D) TO-BE (E) COCOMO Resposta - D

87). O uso do planejamento de recursos empresariais é especificado como uma solução à governança e integração em TI. Pode-se associar essa especificação à necessidade de (A) implantação de ambiente ERP. (B) desenvolvimento e gerenciamento do controle do trâmite de processos.

(C) implantação do sistema de cadastramento de processos.

(D) implantação de GED. (E) uso do RUP. Resposta - A 88) O termo “ferramentas de apoio à decisão” está mais intimamente relacionado ao processo de (A) Data Mining.

(B) Work Flowing.

(C) Data Flow Diagramming.

(D) Computer Supported Cooperative Work.

(E) Drive Modeling Architecture.

Resposta - A 89). Caso se queira implantar a tecnologia GED para organizar os processos documentais, é mister saber que relacionado a ela podem existir vantagens e desvantagens tais como redução de áreas de arquivamento, constantes mudanças de mídia, possibilidade de acesso por mais de um usuário e obrigatoriedade de existência de equipamento e software para recuperação do dado. Esta afirmação apresenta (A) uma vantagem e três desvantagens.

(B) quatro vantagens.

(C) quatro desvantagens.

(D) duas vantagens e duas desvantagens.

(E) três vantagens e uma desvantagem.

Resposta - D 90) O trecho “... considerando, principalmente, aquele feito por pessoas com necessidades especiais” pode ser obtido com páginas web dinâmico cujo estilo possa variar de acordo com a necessidade. Pode facilitar esse processo o uso das implementações de páginas por meio de (A) CMMI (B) CSS (C) AS-IS (D) CMM (E) CRM RESPOSTA - B 91) Especificamente, o termo OLAP se relaciona no texto a (A) mapeamento de processos de negócio.

(B) intrusão e/ou manipulação.

34

(C) gerenciamento de projetos.

(D) Capability Maturity Model.

(E) apoio à decisão.

RESPOSTA - E 92) Três dos principais artefatos da disciplina Requisitos previstos pelo RUP são: (A) Glossário, Especificações Suplementares e Modelo de Casos de Uso. (B) Cronograma, Dicionário de Dados e Diagrama de Casos de Uso. (C) Tabela de Decisões, Registro de Reunião e Plano de Projeto.

(D) Visão, Missão e Valores.

(E) Missão, Modelo de Casos de Uso e Dicionário de Dados.

Resposta A 93) Durante as atividades de Requisitos em um projeto de desenvolvimento de software, são realizadas entrevistas com clientes (usuários e stakeholders, no papel de entrevistados) com o objetivo de levantar suas necessidades e validar as características propostas para o software a ser desenvolvido. Os analistas, no papel de entrevistadores, em geral utilizam dois tipos de perguntas durante as entrevistas: perguntas livres de contexto e perguntas no contexto da solução. Sobre o tema, assinale a afirmativa correta.

(A) Perguntas livres de contexto proporcionam ao analista um entendimento do problema a ser resolvido pelo sistema sem influenciar o entrevistado com detalhes de uma solução que o analista já tenha em mente, baseada em experiências prévias, que pode não ser a mais adequada para o projeto.

possibilita colher mais informações em menor tempo e comparar as respostas para detectar inconsistências.

Resposta A 94) Considere os quatro requisitos registrados em um projeto de uma aplicação para a Internet apresentados a seguir.

I - O tempo de resposta máximo do sistema a qualquer ação do usuário deve ser de 5s.

II - Clientes que tenham pagado as últimas cinco compras à vista têm direito a um desconto não cumulativo de 10% na próxima compra.

III - A interface com o usuário deve ser organizada em abas e menus.

IV- Se o produto possuir uma quantidade máxima permitida por compra, esse limite deve ser imposto pelo sistema durante uma compra. São tipicamente classificados como requisitos funcionais APENAS os requisitos (A) I e II (B) I e III (C) II e III (D) II e IV (E) III e IV Resposta D

(B) Perguntas no contexto da solução devem ser feitas antes das perguntas livres de contexto, de forma que seja possível obter um entendimento inicial do escopo do projeto e testar se a solução proposta coincide com as expectativas dos clientes.

(C) Perguntas no contexto da solução estão relacionadas à identificação das necessidades dos clientes, enquanto perguntas livres de contexto estão relacionadas às características do software a ser desenvolvido.

(D) Um exemplo de pergunta no contexto da solução é “Quem são os usuários (do software a ser desenvolvido)?”.

(E) É consenso nos dias atuais que uma alternativa vantajosa às entrevistas é a distribuição de questionários aos clientes, com perguntas dos dois tipos, o que 35

36