Introdução aos Sistemas de Informação Aula 2 - Processo de Software Material elaborado pelas Profas. Junia e Rosângela

Tamanho: px
Começar a partir da página:

Download "Introdução aos Sistemas de Informação Aula 2 - Processo de Software Material elaborado pelas Profas. Junia e Rosângela"

Transcrição

1 2 Introdução aos Sistemas de Informação Aula 2 - Processo de Software Material elaborado pelas Profas. Junia e Rosângela Um processo de software conjunto de atividades e resultados associados que geram um produto de software. Essas atividades são, em sua maioria, executadas por desenvolvedores sistemas.. Há 4 atividades fundamentais no processo de software: 1. Especificação do Software definição de requisitos e análise de requisitos - a funcionalidade do software e as restrições em sua operação devem ser definidas. 2. Desenvolvimento do Software projeto e implementação - o software deve ser produzido de modo que atenda a suas especificações. 3. Validação do software integração e teste - o software tem de ser validado para garantir que ele faz o que o cliente deseja. 4. Evolução do software o software deve evoluir para atender às necessidades mutáveis do cliente. MODELO DE PROCESSO DE SOFTWARE É a descrição simplificada de um processo de software, que é apresentada a partir de uma perspectiva específica. Os modelos são abstrações do processo real que está sendo descrito. Dentre os modelo de processo destacam-se atividades que são parte do processo de software, produtos de software e o papel das pessoas envolvidas na engenharia de software. Exemplos de tipos de processo. 1. Um modelo de workflow mostra a seqüência de atividade no processo, juntamente com suas entradas, saídas e dependências. As atividades, nesse modelo, representam ações humanas. 2. Um modelo de fluxo de dados ou de atividade representa o processo como um conjunto de atividades, cada uma das quais realiza alguma transformação de dados. Esse modelo mostra como a entrada para o processo, tal como uma especificação, é transformada em uma saída, como um projeto. As atividades podem estar em um nível inferior ao das atividades em um modelo de workflow. Elas podem representar transformações realizadas por pessoas ou computadores. 3. Um modelo de papel/ação representa papéis das pessoas envolvidas no processo de software e as atividades pelas quase elas são responsáveis. Custos da engenharia de software Depende do processo utilizado e do tipo de software que está sendo desenvolvido. O custo total de desenvolvimento de um complexo sistema de software como sendo de cem unidades de custo, a distribuição dessas unidades será semelhante ao mostrado nos esquemas a seguir Especificação Projeto Implementação Integração e teste Se uma abordagem não linear, mas iterativa, com refinamentos sucessivos for utilizada, não existe uma linha exata entre especificação projeto e desenvolvimento Especificação desenvolvimento cíclico e iterativo Teste de sistema Existem também os custos de evolução (manutenção), alteração do software depois que foi colocado em uso Desenvolvimento Evolução do Sistema O que é uma CASE Computer-aided software engineering refere-se a uma ampla gama de diferentes tipos de programas utilizados para apoiar as atividades de processo de software, como análise de requisitos, a modelagem de sistemas, a depuração e os testes. Ferramentas CASE podem também incluir um gerador de códigos que, automaticamente, origina código fonte a partir do modelo de sistema e alguma orientação de processo. Upper-CASE destinada a dar apoio à análise e ao projeto. (apoio às fases iniciais) Lower-CASE destinadas a dar apoio à implementação e aos testes, com os depuradores, sistemas de análise de programa, geradores de casos de testes e editores de programas. Propriedades de um Bom Software Os software devem ser controlados por propriedades intrínsecas a ele, como: tempo de resposta do software à consulta do usuário e a facilidade de compreensão do código do programa. Por exemplo: um sistema bancário tem de ser seguro, um jogo interativo deve ter uma resposta rápida, um sistema de controle de telefonia precisa ser confiável, etc.. Podem ser resumidos na Tabela 1. Tabela 1 Atributos para um bom software Facilidade de Manutenção O software deve ser escrito de modo que possa evoluir para atender às necessidades mutáveis dos clientes. Essas mudanças estão relacionadas ao ambiente de negócios que pode ter constantes mutações Nível de Confiança Tem uma gama de características que incluem confiabilidade, proteção e segurança. O software confiável não deve ocasionar danos físicos ou econômicos, no caso de defeitos no sistema. Eficiência O software não deve desperdiçar os recursos do sistema, como memória e ciclos de processador. A eficiência, portanto, inclui a rapidez de resposta, o tempo de processamento, a utilização de memória, entre outros. Facilidade de Uso Deve ser utilizável, sem esforços indevidos, pelo tipo de usuário para quem foi projeto. Isso significa que ele deve dispor de uma interface apropriada com o usuário e de documentação adequada. O processo de desenvolvimento do software deve ser de qualidade, com essas propriedades garantidas, para que o produto também seja.

2 3 4 Responsabilidade Profissional e ética 1. Confidencialidade respeitar seus empregadores ou clientes, quer tenham ou não assinado um acordo formal, quanto ao sigilo de informações. 2. Competência não devem enganar quanto ao seu nível de competência, ou seja, não devem aceitar serviços que estejam fora do seu limite de competência. 3. Direitos de propriedade intelectual estar cientes das leis locais que regulam o uso da propriedade intelectual, como patentes e direitos autorais. Eles devem ser cuidadosos, a fim de assegurar que a propriedade intelectual de empregadores e clientes seja protegida. 4. Má utilização de computadores não empregar suas habilidades técnicas para o mau uso de computadores de outras pessoas. Abrange desde casos triviais jogar no computador do cliente- até casos sérios disseminação de vírus. Existem sociedade e instituições profissionais que desempenham importante papel a esse respeito ACM (Association for Computing Machinery), o IEEE (Institute of Electrical am d Electronic Engineers) e a British computer Society publicam um código de conduta profissional ou código de ética. Esses itens não podem ser pensados antecipadamente. Sistemas e seu ambiente Sistemas não são entidades independentes, mas existem em um ambiente. Esse ambiente afeta o funcionamento e o desempenho do sistema. A figura 1 mostra alguns dos sistemas que podem ser incorporados em um edifício de escritórios, subsistemas. Cidade Rua Edifício Sistema de Sistema de Sistema de Aquecimento energia água Sistema de Sistema de Sistema de Segurança iluminação esgoto Engenharia de Sistemas É a atividade de especificar, projetar, implementar, validar, implantar e manter os sistemas como um todo. Os engenheiros de sistema não se ocupam apenas com o software, mas com as interações de software, hardware e sistema com os usuários e seu ambiente. (recordar conceitos de sistemas) Propriedades emergentes de sistemas São as propriedades (atributos) do sistema como um todo, muitas vezes é difícil prever os valores dessas propriedades com antecedência. Tipos de propriedades: 1. funcionais: que aparecem quando todas as partes de um sistema trabalham em conjunto para atingir algum objetivo. Ex: bicicleta propriedade funcional de ser um dispositivo de transporte. 2. não funcionais: confiabilidade, desempenho, segurança e proteção. Essas propriedades se relacionam com o comportamento do sistema em seu ambiente operacional. EX: Confiabilidade de sistema é um conceito complexo, deve-se levar em conta componentes individuais. Pode-se falar em: a) Confiabilidade de hardware qual a probabilidade de um componente de hardware falhar e quanto tempo leva para reparar esse componente? b) Confiabilidade de software qual é a probabilidade de que um componente de software venha a produzir uma saída incorreta? (diferente da falha de hardware, pois o software não se desgasta), ele pode prosseguir em operação mesmo depois que um resultado incorreto tenha sido produzido. c) Confiabilidade de operador qual a probabilidade de que o operador de um sistema cometa um erro? Figura 1 - Hierarquia de Sistemas O ambiente local do sistema de segurança, por exemplo, são os outros sistemas dentro do edifício. Enquanto que o ambiente total inclui todos os outros sistemas do lado de fora do edifício, na rua e na cidade, bem como os sistemas naturais. O sistema é concebido para produzir mudanças em seu ambiente. Assim, um sistema de aquecimento modifica seu ambiente, aumentando ou diminuindo a temperatura. O funcionamento correto do sistema, portanto, somente pode ser avaliado pelos efeitos sobre o ambiente. O funcionamento de um sistema pode ser afetado pelas mudanças de seu ambiente, exemplo: sistema elétrico em um edifício pode ser afetado por mudanças ambientais do lado de fora do edifício: cabo de força pode ser cortado e o edifício ficara sem energia. Como existe o ambiente físico, existe também o ambiente organizacional, que inclui políticas e procedimentos que são, por sua vez, regidos por questões políticas, econômicas, sociais e ambientais mais amplas. Fatores humanos e organizacionais provenientes do ambiente do sistema que afetam o projeto de sistema destacam-se: 1. Mudanças no processo O sistema requer mudanças nos processos de trabalho, no ambiente? Se sim, há necessidade de treinamento especifico. Se as mudanças forem significativas envolvendo pessoas e ate perda de empregos, os usuários podem resistir ao sistema. 2. Mudanças nas tarefas Os sistemas diminuem a habilidade dos usuários em um ambiente ou faz com que eles modifiquem o modo como trabalham? Se sim, eles podem resistir à introdução do sistema na organização. Projetos que envolvem gerentes que precisam mudar seu modo de trabalhar, para a adequação ao sistema de computadores, freqüentemente se ressentem disso. Gerentes podem achar que seu status na organização está sendo reduzido, em virtude desse sistema.

3 3. Mudanças organizacionais - sistema modifica a estrutura de poder político em uma organização? Exemplo, se uma organização depende de um sistema complexo, aqueles que sabem operar o sistema têm bastante poder político. Modelagem de sistemas Como parte dos requisitos do sistema e da atividade de projetos, o sistema precisa ser modelado como um conjunto de componentes e de relações entre esses componentes Modelo de arquitetura. A arquitetura do sistema é retratada como um diagrama de blocos, mostrando os subsistemas principais e as inter-conexões entre eles. Cada subsistema é representado por um retângulo, no diagrama de blocos; as flechas indicam a existência de uma relação entre eles (Figura 2). Sensores de movimento Sirene Figura 2 - Componentes principais do Sistema de alarme contra intrusos Tabela 2 - Funcionalidade de subsistemas no sistema de alarme Subsistema Descrição Sensor de movimento Detecta movimento nos cômodos monitorados pelo sistema Sensor de porta Detecta a abertura de porta nas portas externas do edifício Controlador de alarme Controla a operação do sistema Sirene Emite um aviso sonoro quando um intruso é detectado. Sintetizador de voz Sintetiza uma mensagem de voz dando a localização do possível intruso Discador de telefone Faz as chamadas externas para avisar a segurança, a policia, etc.. O sistema é decomposto em subsistemas. Cada subsistema pode ser representado da mesma maneira até que o sistema seja decomposto em componentes funcionais única função, Tabela 2. Historicamente o modelo de arquitetura foi utilizado para identificar componentes de hardware e software que possam ser desenvolvidos em paralelo. Contudo, essa distinção (hardware/software) está se tornando irrelevante. Assim, atualmente, é mais apropriado classificar os subsistemas de acordo com sua função, antes de serem tomadas decisões sobre as vantagens e as desvantagens referentes a hardware/software. Componentes funcionais de sistemas Controlador de alarme Sintetizador de voz Sensores de porta Discador de telefone Centro de controle externo 5 1. Componentes de sensores coletam informações do ambiente do sistema. Exs: radares em um sistema de controle de tráfego aéreo, sensores de posicionamento de papel em uma impressora, um par termoelétrico em uma fornalha. 2. Componentes de atuadores causam alguma mudança no ambiente do sistema. Exs: válvulas que se abrem e fecham para passagem de líquidos, superfícies de vôo em uma aeronave, que controlam o ângulo de vôo, e o mecanismo de alimentação de papel em uma impressora. 3. Componentes de computação aqueles que considerando alguma entrada realizam algumas computações sobre essa entrada e produzem uma saída. Ex: processador de ponto flutuante que realiza computações sobre os nros reais. 4. Componentes de comunicação aqueles cuja função é coordenar uma operação com outros componentes. Exs: um escalador em um sistema de tempo real, que decide quando os diferentes processos devem ser escalados para serem executados em um processador. 5. Componentes de interface que transformam a representação utilizada por um componente de sistema em uma representação empregada por outro componente. EX:um componente de interface humana, que considera algum modelo de sistema e o exibe para o operador humano. Conversor analógico-digital que converte uma entrada analógica em saída digital. Considerando esses componentes para o exemplo anterior tem-se a Tabela 3. Tabela 3 Componentes de sistemas e suas funções Tipos de componentes Componentes Função Sensor Sensor de movimento, sensor de porta Detecta movimento nos cômodos monitorados pelo sistema. Detecta a abertura de porta nas portas externas do edifício Atuador Sirene aviso sonoro quando um intruso é detectado Comunicação Discador de telefone Aciona o centro de controle externo para emitir um aviso de intrusão. Recebe comandos do centro de controle. Coordenação Controlador de alarme Coordena todos os componentes do sistema. Atua nos comandos do painel de controle e do cento de controle. Interface Sintetizador de voz Sintetiza mensagem dando a localização da intrusão. O processo de engenharia de sistemas Engenharia de sistemas x engenharia de software existem importantes distinções: a) envolvimento interdisciplinar diferentes disciplinas de engenharia podem estar envolvidas na engenharia de sistemas. Há uma imensa possibilidade de mal-entendidos devido à terminologia diferente utilizada por diferentes engenheiros. b) Possibilidade reduzida de refazer o trabalho durante o desenvolvimento de sistemas altos custos para mudanças, por ex, mudar a localização de radares em um sistema de controle de trafego aéreo. Software se tornou importante para os sistemas, pois ele permite flexibilidade, devido às mudanças durante o desenvolvimento do sistema, em resposta a novos requisitos. Engenharia de sistemas atividade interdisciplinar que envolve equipes com diferentes formações técnicas. As fases são as mostradas na Figura 3: 6

4 8 Especificação de requisitos Projeto do sistema Especificação de Requisitos Desenvolvimento de subsistema Integração do sistema Instalação do sistema Figura 3 Processo de engenharia de sistemas Desativação do sistema Evolução do sistema Um completo entendimento dos requisitos do software é essencial para o sucesso de um esforço de desenvolvimento de software. A atividade de especificação de requisitos é um processo de descoberta, refinamento, e modelagem. O escopo do software definido no planejamento do projeto é refinado em detalhe, as funções e o desempenho do software são especificados, as interfaces com outros sistemas são indicadas e as restrições que o software deve atender são estabelecidas. Modelos dos dados requeridos, do controle e do comportamento operacional são construídos. Finalmente, critérios para a avaliação da qualidade em atividades subseqüentes são estabelecidos. Os principais profissionais envolvidos nesta atividade são o engenheiro de software (muitas vezes chamado analista) e o cliente / usuário. A atividade a ser desenvolvida é capturar os requisitos sob uma perspectiva dos usuários, isto é, os modelos gerados procuram definir as funcionalidades e restrições que devem ser consideradas para atender às necessidades dos usuários; A etapa de Especificação de Requisitos é independente do modelo de processo escolhido, uma vez que trata os requisitos do sistema sob uma perspectiva externa. *************************** Definição de Requisitos gerais (funcionais e não funcionais) de um sistema Levantar os requisitos do sistema como um todo, envolve consultas com os clientes e usuários finais do sistema. Três tipos de requisitos compõem essa atividade: 1- Requisitos funcionais abstratos funções básicas que o sistema deve oferecer, definidas em um nível abstrato. A especificação detalhada de requisitos funcionais ocorre no nível de subsistema. Ex: controle de tráfego aéreo, essa atividade de definição de requisitos, provavelmente, identificaria a necessidade de uma base de dados de plano de vôo para armazenar os planos de vôos de todas as aeronaves que ingressarem no espaço aéreo controlado. 2- Propriedades de sistemas são propriedades emergentes de sistemas não funcionais. Podem incluir propriedades como desempenho, segurança, entre outras. Afetam os requisitos de todos os subsistemas. 3- Características que o sistema não deve exibir especificar o que o sistema não deve fazer e quanto ele deve fazer. Por ex, no sistema de trafego aéreo, o sistema não deve apresentar muitas informações ao controlador. É importante: estabelecer os objetivos gerais que o sistema deve cumprir. EX: Considere um sistema, para um prédio de escritórios, que deve oferecer proteção contra incêndios e detecção de intrusos. Declaração de Objetivos: Fornecer um sistema de alarme contra incêndios e contra intrusos para o edifício, com o objetivo de divulgar avisos internos e externos referentes a incêndios ou à entrada de pessoa não autorizada. Existem níveis de requisitos que devem ser respeitados para que se tenha uma boa definição de requisitos: - Requisitos dos usuários - para designar os requisitos abstratos de alto nível. São declarações, em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sob as quais deve operar. Devem ser escritos para gerentes do clientes e dos fornecedores que não tenham um conhecimento detalhado do sistema. - sistema - para indicar a descrição detalhada que o sistema deverá fazer. Estabelecem detalhadamente as funções e as restrições de sistemas. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional, deve ser preciso e pode servir como um contrato entre o comprador do sistema e o desenvolve-dor de software. Devem ter como alvo os profissionais técnicos de nível sênior e os gerentes de projeto. - Especificação de projeto de software é uma descrição abstrata do projeto de software que é uma base para o projeto e a implementação mais detalhados. Essa especificação acrescenta detalhes à especificação de requisitos do sistema. É um documento orientado à implementação, deve ser escrito para os engenheiros de software que desenvolverão o sistema. Exemplos: Requisitos do usuário: 1. O software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas. Requisitos do sistema: 1.1. O usuário deve dispor de recursos para definir o tipo dos arquivos externos Cada tipo de arquivo externo pode ter uma feramenta asscoiada que pode ser aplicada a ele Cada tipo de arquivo externo pode ser representado como um ícone especifico na tela do usuário Devem ser fornecidos recursos para o ícone que representa um arquivo externo, a ser definido pelo usuário Quando um usuário seleciona um ícone que representa um arquivo externo, o efeito dessa seleção é aplicar a ferramenta associada como tipo de arquivo externo representado pelo ícone selecionado. A Tabela 4 apresenta os diferentes leitores para os tipos de especificação de software.

5 Tabela 4 Leitores para os diferentes tipos de especificação Requisitos dos usuários Gerentes de clientes, usuários finais de sistemas, engenheiros de clientes, gerentes do fornecedor, arquitetos de sistemas sistema Usuários finais de sistemas, engenheiros do cliente, arquitetos de sistemas, desenvolvedores de software. Especificação de projeto Engenheiros do cliente (talvez), arquitetos do sistema, de software desenvolvedores de software. Definindo Requisitos Funcionais e Não Funcionais Requisitos funcionais: São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais, podem também explicitamente declarar o que o sistema não deve fazer. Especificação deve ser completa e consistente. Completa que todas as funções requeridas pelo usuário devem estar definidas. Consistente requisitos não devem ter informações contraditórias. A maioria dos problemas na especificação/desenvolvimento de sistemas ocorre devido ao não cuidado nessa fase. Requisitos não funcionais: São aqueles que não dizem respeito diretamente às funções específicas fornecidas pelo sistema. Eles podem estar relacionados a propriedades de sistemas como : confiabilidade, tempo de resposta e espaço em disco. Como alternativa, eles podem definir restrições para o sistema como a capacidade dos dispositivos de E/S e as representações de dados utilizadas nas interfaces de sistema. O não cumprimento de um requisito não funcional pode tornar o sistema inútil. Exemplo: Se um sistema de aviação não atender aos seus requisitos de confiabilidade, ele não será atestado como seguro para operação; se um sistema de tempo real falhar em cumprir com seus requisitos de desempenho, as funções de controle não operarão corretamente. Os requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido. Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para desenvolver o sistema. Exemplos: Especificação de padrões de qualidade, que deve ser utilizada no processo, uma especificação de que o projeto deve ser produzido com um conjunto especificado de ferramentas CASE e uma descrição de processo a ser seguido. A Figura 4 exibe os tipos de requisitos não funcionais existentes. 1. produtos: são os requisitos que especificam o comportamento do produto. Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de facilidade de uso. 2. produtos: são os requisitos que especificam o comportamento do produto. Entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve operar e a quantidade de memória que ele requer, os requisitos de confiabilidade, que 9 estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os requisitos de facilidade de uso. Requisitos não funcionais Requisitos do produto Requisitos organizacionais Requisitos externos facilidade de uso confiabilidade eficiência portabilidade entrega implementação padrões interoperabilidade éticos legais Figura 4 - Classificação dos Tipos de Requisitos Não Funcionais desempenho espaço privacidade segurança 3. Requisitos organizacionais: são procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. Exemplos: padrões de processo que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou o método de projeto utilizado, e os requisitos de fornecimento, que especificam quando o produto e seus documentos devem ser entregues. 4. Requisitos externos: abrange todos os requisitos procedentes de fatores externos ao sistema e a seu processo de desenvolvimento. Dentre eles destacam-se os requisitos de interoperabilidade, que definem como o sistema interage com outras organizações, os requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com a lei, e os requisitos éticos. Os requisitos éticos são definidos em um sistema para garantir que este será aceitável para seus usuários e o publico em geral. 10

6 11 12 Exemplos de requisitos não funcionais Requisito de produto: Deve ser possível que toda a comunicação necessária entre o ambiente APSE e o usuário seja expressa no conjunto-padrão de caracteres Ada. Requisito organizacional: O processo de desenvolvimento de sistema e os documentos a serem entregues deverão estar de acordo com o processo e os produtos a serem entregues, definidos em XYZCo-SP-STAN-95. Requisito Externo: O sistema não deverá revelar aos operadores nenhuma informação pessoal sobre os clientes, além de seus nomes e o número de referencia. Tratamento dos usuário Problemas e formas de Solução Os requisitos de usuário para um sistema devem descrever os requisitos funcionais e não funcionais de modo compressível pelos usuários do sistema que não têm conhecimentos técnicos detalhados. Eles devem especificar somente o comportamento externo do sistema, evitando tanto quanto possível as características de projeto de sistema. Conseqüentemente, não devem ser definidos utilizando-se um modelo de implementação. Eles podem ser descritos com o uso de linguagem natural, formulários e diagramas intuitivos simples. Problemas que normalmente ocorrem: 1- Falta de clareza é difícil utilizar a linguagem de maneira precisa e sem ambigüidade, sem produzir um documento de difícil leitura. 2- Confusão de requisitos quando os requisitos funcionais e não funcionais, os objetivos do sistema e as informações sobre o projeto não estão claramente definidos. 3- Fusão de requisitos quando vários requisitos diferentes são expressos junto como um único requisito. Diretrizes para redação de requisitos: 1. Adote um formato-padrão e certifique-se de que todas as definições de requisitos estejam conforme esse formato. Padronizar o formato significa que as omissões podem ser menos freqüentes e faz com que os requisitos sejam verificados com mais facilidade. O formato que utilizo inclui reforçar o requisito inicial, considerando uma declaração da lógica, com cada requisito de usuário e uma referencia à especificação mais detalhada de requisitos de sistema 2. Utilize a linguagem de modo consistente. Em particular, faça distinção entre os requisitos obrigatórios (utiliza-se o verbo deve) e os que são desejáveis (utiliza-se o verto deveria). 3. Utilize destaques no texto (negrito ou itálico) para ressaltar partes importantes dos requisitos. 4. Evite, tanto quanto possível, o uso de jargões de informática. Contudo, ocorrerá que termos técnicos detalhados, utilizados no domínio da aplicação do sistema, sejam incluídos nos requisitos dos usuários. Tratamento dos sistema São descrições mais detalhadas dos requisitos dos usuários. Eles podem servir de base para um contrato destinado à implementação do sistema e, portanto, devem ser uma especificação completa e consistente de todo o sistema. São utilizados pelos engenheiros de software como ponto de partida para o projeto de sistema. Os requisitos de sistema deveriam em principio definir o que o sistema deveria fazer, e não como ele teria de ser implementado. A linguagem natural por ser ambígua pode gerar problemas nesse documento. Dessa forma existem outras formas: linguagem natural estruturada, linguagem de descrição de projeto, notações gráficas, especificações matemáticas. Formalização: O documento de requisitos de software É a declaração oficial do que é exigido dos desenvolvedores de sistema. Ele deve incluir os requisitos de usuário para um sistema e uma especificação detalhada dos requisitos de sistema. Algumas vezes, esses dois tipos de requisitos podem ser integrados em uma única descrição. Em outros casos, os requisitos de usuários são definidos em uma introdução à especificação dos requisitos de sistema. Podem ser apresentados em documentos separados se possuírem um número grande de requisitos. Vários usuários utilizam o documento de requisitos: Conselhos de Heninger (1980) sobre seis requisitos aos quais um documento de requisitos de software deveria satisfazer: 1. Especificar somente o comportamento externo do sistema. 2. Especificar as restrições à implementação 3. Ser fácil de ser modificado 4. Servir como uma ferramenta de referencia para os responsáveis pela manutenção do sistema 5. Registrar a estratégia sobre o ciclo de vida do sistema 6. Caracterizar respostas aceitáveis para eventos indesejáveis. A Tabela 5 apresenta os diferentes usuários de um documento de requisitos e a forma como o utilizam. Tabela 5 Usuários de um documento de requisitos Usuários Utilização Clientes de sistema Especificam os requisitos e os têm para verificar se eles atendem a suas necessidades. Especificam mudanças nos requisitos Gerentes Utilizam o documento para planejar um pedido de proposta para o sistema e para planejar o processo de desenvolvimento do sistema Engenheiros de sistema Utilizam os requisitos para compreender que sistema deve ser desenvolvido Engenheiros de teste de Utilizam os requisitos para desenvolver testes de validação sistema para o sistema. Engenheiros de manutenção Utilizam os requisitos para ajudar a compreender o sistema de sistema e as relações entre suas partes. Padrão do IEEE IEEE/ANSI Um padrão sugerido para o documento de requisitos tem a seguinte estrutura e foi proposta pelo IEEE. 1. Introdução

7 1.1 Propósito Deve delinear o propósito do documento de requisitos. 1.2 Escopo do produto Deve identificar, pelo nome, o software a ser produzido; deve explicar, o que o software fará e, se necessário, o que ele não fará. 1.3 Definições, Acrônimos e Abreviações Deve fornecer as definições de todos os termos, acrônimos e abreviações utilizados no documento, para que se possa interpreta-lo adequadamente. 1.4 Visão Geral do restante do documento Deve descrever o restante do documento de requisitos e explicar como esse documento está organizado. 2. Descrição Geral Descreve os fatores gerais que afetam o produto e seus requisitos. Essa seção não declara requisitos específicos. Ao invés disso, ela fornece um background para os requisitos específicos, os quais são definidos em detalhes na Seção Perspectiva do produto Deve colocar o produto em perspectiva com outros produtos relacionados. Se o produto é independente e totalmente auto-contido, esse fato deve ser declarado aqui. Se o Documento de fine um produto que é um componente de um sistema maior, como freqüentemente ocorre, então essa subseção deve relatar os requisitos daquele sistema maior que têm alguma relação com a funcionalidade do software identificando as interfaces entre aquele sistema e o software em questão. 2.2 Funções do Produto Deve fornecer um resumo das maiores funcionalidades que o software deve realizar. 2.3 Características do Usuário Deve descrever as características gerais dos usuários do produto, incluindo nível de educação, experiência e conhecimento técnico. 1.4 Restrições Gerais Deve descrever as restrições que o sistema tem. 2.5 Suposições e Dependências Deve listar cada um dos fatores que afetam os requisitos declarados na Seção Requisitos Deve conter todos os requisitos do software (funcionais, não funcionais e de interface) em um nível de detalhe suficiente para permitir que os projetistas possam elaborar um projeto que satisfaça esses requisitos. Os requisitos podem ser divididos em Requisitos Funcionais e Requisitos não funcionais. Cada requisito declarado deve possuir uma identificação única. 3.1 Requisitos funcionais descrição entrada exigida processamento 13 saída gerada 3.2 Requisitos não funcionais do produto organizacionais externos 3.3 Atributos Conter todos os atributos necessários para o software. Exs: de confiabilidade, segurança, portabilidade, manutenção. 4. Apêndices 5. Índice A estrutura de um documento de requisitos pode conter modificações, a partir da proposta do IEEE: Capítulo Descrição Prefácio Definir o público alvo a que se destina o documento e descrever seu histórico da versão, incluindo lógica para a criação de uma nova versão e um sumário das mudanças feitas em cada versão. Introdução Deve descrever: a necessidade do sistema, brevemente suas funções e explicar como ele deverá operar com outros sistemas; como o sistema se ajusta aos negócios em geral ou aos objetivos estratégicos da organização que está solicitando o software. Glossário Deve definir os termos técnicos utilizados no documento. Não deve fazer suposições sobre a experiência ou o conhecimento do leitor. Definição de Descrever os serviços fornecidos para o usuário e os requisitos não requisitos de usuário funcionais do sistema. Podem ser utilizadas: linguagem natural, diagramas ou outras notações que sejam compreensíveis pelo cliente. Arquitetura de Apresentar uma visão geral de alto nível da arquitetura prevista de sistemas sistema, mostrando a distribuição de funções por meio de módulos de sistemas. Se houver reuso, os componentes devem ser destacados. Especificação de Descrever requisitos funcionais e não funcionais com mais requisitos do sistema detalhes. Modelos de Sistema Devem mostrar o relacionamento entre os componentes de sistema e o sistema e seu ambiente. Podem ser modelos de fluxos de dados, de objetos, etc. Evolução do sistema Devem ser descritas as suposições fundamentais nas quais o sistema se baseia e as mudanças previstas, devidas à evolução do hardware, mudanças de usuário, etc. Apêndices Detalhes e informações específicas relacionadas à aplicação que está sendo desenvolvida (Exs: descrições de hardware, banco de dados) Índice Alfabético, índice de diagramas, de funções, etc.. Referencia Bibliográfica: Engenharia de Software Ian Sommerville, 6 a edição, Addison Wesley,

8 15 16 Dicas Para a elaboração do Documento de Requisitos "Sei que você acredita que entendeu o que acha que eu disse, mas não estou certo de que aquilo que ouviu não é o que eu pretendia dizer". Possibilitando ao Engenheiro de Software: especificar a função e o desempenho do software indicar a interface do software com outros elementos do sistema estabelecer quais são as restrições de projeto que o software deve enfrentar construir modelos do processo, dos dados e dos domínios comportamentais. traduzir em um projeto procedimental, arquitetônico e de dados a representação da informação e a função. Para se obter a declaração do escopo do sistema (1.2 IEEE) deve-se seguir os seguintes passos: 1. entender as funções globais do sistema 2. descrever a função principal do sistema 3. identificar as principais entradas e saídas 4. listar todas as restrições que afetam o sistema 5. escrever um parágrafo claro 1. - Entender as funções globais do sistema Antes que o processo de engenharia de software comece, deve-se entender as principais funções do sistema computacional e o papel do software dentro do sistema. Idealmente, uma descrição detalhada das funções do sistema seria fornecida pelo cliente. No entanto, na realidade, o analista deve formular uma série de questões para o cliente a fim de descrever suas necessidade de maneira concisa e não ambígua. O conjunto inicial de questões deve focalizar as saídas: Que tipo de informação ou sinais de controle o sistema deve produzir? Qual é o formato, o conteúdo e a estrutura de dados de saída? Eles são produzidos na forma de relatório, necessita de periféricos gráficos ou em algum formato especial? Quem faz uso dos dados de saída? Outros sistemas fazem uso dos dados de saída? Respostas a tais questões auxiliam o analista a isolar os principais objetivos do sistema e fornecem indicações implícitas das funções do sistema. O segundo conjunto de questões deve focalizar as entradas: Quais as informações ou sinais de controle o sistema deve aceitar como entrada? Os dados de entrada são fornecidos através de um diálogo interativo homem-máquina? Qual é o nível de validação de dados requerida? Qual é o formato dos dados de entrada? Quem fornece os dados? Respostas às questões de entrada e saída fornecerão informações substanciais sobre as funções do sistema. O terceiro conjunto de questões é formulado para melhor compreender as funções do sistema. São desenvolvidas questões para esclarecer cada função inferida. Essas respostas em conjunto com as anteriores permitem escrever a declaração do escopo do sistema Descrever a função principal do sistema Normalmente, essa função é expressa em um parágrafo que identifica o principal objetivo do sistema computacional. Utiliza uma linguagem clara para descrever: Qual a função o sistema irá realizar As informações necessárias As informações produzidas Por exemplo, uma declaração do escopo para um programa de integração numérica pode ser: Será desenvolvido um sistema que utiliza técnicas numéricas para calcular a integral de uma função f(x) entre os valores a e b. Apenas funções da forma: f(x) = px 3 + qx 2 + rx + s serão consideradas. A declaração do escopo pode levar a muitas outras questões. O sistema é computadorizado ou manual? Qual o nível de precisão desejado? Como são fornecidas as funções f(x) e os valores limites a e b? Com que velocidade a integração deve ser feita? Com o refinanciamento da declaração do escopo (após as respostas destas e outras questões), duas coisas acontecem: a função é identificada e analisada, e o papel de cada elemento é determinado. Por exemplo, se apenas uma aproximação é requerida, a velocidade não for importante, e o método de implementação não importa, a melhor alocação pode ser puramente manual integração gráfica usando papel e caneta. Os elementos apropriados seriam pessoa, instruções (procedimentos) e uma representação gráfica de f(x) no papel (informação). Por outro lado, se for necessária uma alta precisão e milhões de integrações por minuto, uma solução baseada em computador é indicada. Nestes casos, os elementos apropriados do sistema seriam: hardware, software, pessoas, documentos, informação e procedimentos. Para começar uma abordagem mais sistemática, considere um problema mais complicado: um piloto automático. Uma declaração do escopo poderia ser descrita inicialmente como: O sistema Piloto- automático irá manter constante a velocidade do automóvel uma vez que ela tenha sido indicada pelo motorista. A velocidade irá ser mantida até que o sistema seja desligado ou até que o motorista pressione o freio. A declaração acima descreve tanto os objetivos do sistema como sua função principalmente. Indica também a informação requerida (uma velocidade indicada) e produzida (manter a velocidade

9 17 18 constante). Porém, muitos detalhes não foram tocados. A descrição dos objetivos e da principal função do sistema está em muito alto nível. Isto é, detalhes funcionais não foram descritos, não foram identificadas as entradas e saídas específicas, e detalhes de implementação foram omitidos. É importante notar, no entanto, que estas omissões são completamente aceitáveis no inicio. O objetivo é desenvolver uma declaração inicial do escopo que descreve a função principal do sistema. Pode parecer desnecessário e redundante desenvolver uma declaração do escopo para o sistema Piloto automático. Porém deve se ter em mente que: Todos sabem o que o sistema deverá fazer até que alguém decida descreve-lo. Uma declaração de escopo deve ser o mais simples possível no início. A primeira declaração os rascunho das principais funções do sistema devem ser sentenças simples (sujeito, verbo e objeto). Por exemplo, uma primeira declaração de um sistema de piloto automático poderia ser: O sistema piloto automático mantém constante a velocidade do automóvel. Interações subseqüentes dessa sentença pode refinar o sujeito, verbo e objeto, para fornecer maiores detalhes e menor ambigüidade Identificar as principais entradas e saídas Independente da área de aplicação, todo sistema computacional transforma informações. Isto é, dados fornecidos são transformados pelo sistema para produzir dados de saídas.o próximo passo na criação de uma declaração de escopo é uma descrição das principais entradas e saídas do sistema computacional. Durante os primeiros estágios do trabalho de análise, sempre é útil classificar os dados transformados pelo sistema em duas grandes categorias genéricas: itens de dados e itens de controle Um item de dados é qualquer entrada ou saída do sistema cujo conteúdo da informação é transformado (isto é, modificado, reorganizado, calculado, combinado) pelo elemento software. Em geral, algoritmos computacionais ou combinatoriais transformam itens de dados de uma forma ou de outra. Um item de controle geralmente implica na ocorrência de uma ação ou evento específico, ou requisito a inicialização de uma ação ou evento específico. Para ilustrar a diferença entre itens de dados e itens de controle, considere que o sistema Piloto automático permite ao motorista definir a velocidade desejada usando um teclado numérico do painel. A velocidade desejada é um item de dados isto é, uma entrada do sistema que é processada pelo software e transformada em velocidade. Para desligar o sistema, o motorista deve pressionar o freio ou o botão de desliga. Ambas ações causam um pulso que é lido pelo software. Devido ao pulso não ser transformado (modificado, reorganizado, calculado, combinado) de alguma forma, mas representar um evento que provoca uma mudança imediata na função do sistema, ele será considerado um item de controle Listar todas as restrições que afetam o sistema A especificação e projeto de um sistema computacional são restringidos por muitas razões: Considerações econômicas podem limitar tanto os recursos técnicos como humanos. As características de um elemento do sistema podem restringir a maneira como um outro elemento do sistema é especificado e, conseqüente, projetado. ambiente e que o sistema será desenvolvido poderá impor restrições quando as funções e desempenho do sistema. É importante reconhecer que atitudes fatalistas podem, muitas vezes, ser improdutivas. Embora o hardware tenha sido selecionado, pode não ser tão tarde efetuar mudanças, se as restrições impostas no software forem tão severas que: (1) uma quantidade exorbitante de tempo seja necessária para desenvolver o software, aumentando dramaticamente o custo de desenvolvimento; (2) a habilidade de alcançar o desempenho de controle esteja em risco ou (3) modificações no sistema operacional sejam possíveis. Por listar as restrições, está se conduzindo uma revisão implícita. Por exemplo, considere o desenvolvimento de uma rede de caixas eletrônicas para um grande banco. O sistema é composto de diferentes computadores e softwares, uma base de dados, operadores humanos, e substancial documentação e procedimentos. A capacidade de processamento do hardware, a organização da base de dados, os registros impostos para operadores humanos (clientes do banco), e muitos outros fatores irão criar um conjunto de restrições para o sistema. Além disso, a natureza da aplicação dita as suas próprias restrições implícitas: 1. A necessidade da segurança apropriada para proteger os interesses do banco e de seus clientes 2. A necessidade da disponibilidade de um caixa ao cliente 3. A necessidade de expandir a rede de acordo com o crescimento do banco 4. A necessidade de estender características e funções devido à pressões da concorrência. Cada uma dessas restrições implícitas deve ser listada nesta fase. Cada uma implica que certos elementos do sistema devem ter características especificas e, em muitos casos, especificas funções de desempenho Escrever um parágrafo claro Se tiver sido realizado cada um dos passos associados com o desenvolvimento de uma declaração de escopo, têm-se agora as seguintes informações: Uma descrição da função principal do sistema. Uma lista das principais entradas e saídas. Uma lista de restrições que afetam o sistema. Estas informações são a base para um parágrafo claro que descreva todas as operações e características do sistema. O parágrafo deve descrever as funções importantes do sistema de forma objetiva, correta e simples. Deve conter referências á item de dados e de controle e, também, a maneira como eles interagem com as principais funções do sistema. Devido ao parágrafo ser a entrada essencial os próximos passos da análise de sistemas, ele deve ser desenvolvido com muito cuidado. De fato, é sempre vantajoso desenvolver o parágrafo interativamente. Isto é, começa-se a escrever um rascunho inicial, então se faz refinamentos, até a versão final. A cada elaboração da declaração do escopo as ambigüidades devem ser eliminadas e mais detalhes são fornecidos. Para ilustrar, considere o rascunho inicial da declaração de escopo do sistema Piloto-automático. O sistema "Piloto-automático" mantém constate a velocidade do automóvel.

10 19 Embora este rascunho defina a principal função do sistema, fornece poucos detalhes e deve ser refinado. Após dialogar com o cliente, escreve-se: O sistema Piloto automático irá manter constante a velocidade do automóvel uma vez que ela tenha sido indicada pelo motorista. A velocidade irá ser mantida até que o sistema seja desligado ou até que o motorista pressione o freio. Melhor, mais ainda vago. Existe a necessidade de se conhecer qual é a variação da velocidade aceitável, qual o mecanismo que será usado para indicar a velocidade, qual o mecanismo será usado para desligar o sistema. Além disso, falta determinar alguns requisitos implícitos ou restrições (por exemplo: características de segurança). Note-se, no entanto, que não há necessidade de se determinar como o sistema irá realizar esta função. Isso será feito posteriormente. Neste ponto, o enfoque está sobre o problema e não sobre como resolve-lo. O terceiro rascunho pode ser: O sistema "Piloto Automático" mantém constate a velocidade do automóvel, podendo variar ±3 milhas por hora (mph) de um valor nominal especificado pelo motorista. O valor da velocidade nominal é indicado pelo motorista de duas formas: (1) ou pressionando-se um botão set speed enquanto o automóvel estiver andando com velocidade igual ou maior que 45 mph, ou (2) teclando-se a velocidade desejada no painel do carro. O dado da potência será monitorado em intervalos de 0,1 segundo e a média calculada a cada segundo. O sistema irá ajustar a velocidade a cada segundo. O sistema é automaticamente desligado quando a velocidade nominal ficar abaixo de 45 mph. Além disso, o motorista pode desligar o sistema pressionando o freio ou pressionando o botão off. Em cada elaboração, maiores detalhes são fornecidos e futuras questões são levantadas e respondidas. O processo termina quando o analista der-se por satisfeito, ou seja, não tiver mais questões a levantar. Para execução desse processo de definição do escopo do sistema, várias técnicas podem ser utilizadas. A seguir, são apresentadas as principais técnicas para apoiar a etapa de levantamento de requisitos.

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.

Leia mais

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software

CCE 876 - Engenharia de Software. Introdução à Engenharia de Software CCE 876 - Engenharia de Software Introdução à Engenharia de Software Objetivos Introduzir a Engenharia de Software e explicar sua importância. Introduzir os conceitos principais relacionados à Engenharia

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Engenharia de Sistemas Computacionais

Engenharia de Sistemas Computacionais Engenharia de Sistemas Detalhes no planejamento UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Introdução Na aplicação de um sistema

Leia mais

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos

Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Engenharia de Software Engenharia de Software 2012/3 Aula 4 Engenharia de Requisitos Thiago P. da Silva thiagosilva.inf@gmail.com Agenda Engenharia de Requisitos Níveis de Descrição dos Requisitos Tipos

Leia mais

ENGENHARIA DE REQUISITOS

ENGENHARIA DE REQUISITOS Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE

Leia mais

REQUISITOS. Prof. Msc. Hélio Esperidião

REQUISITOS. Prof. Msc. Hélio Esperidião REQUISITOS Prof. Msc. Hélio Esperidião OS REQUISITOS O que são requisitos? Uma descrição de um serviço ou de uma limitação O que é a engenharia de requisitos? O processo envolvido no desenvolvimento de

Leia mais

Objetivos desta Aula. Introdução a Engenharia de Software Capítulo 1. Sumário. Engenharia de Software. Custos do Software. Custos do Software

Objetivos desta Aula. Introdução a Engenharia de Software Capítulo 1. Sumário. Engenharia de Software. Custos do Software. Custos do Software Objetivos desta Aula Introdução a Engenharia de Software Capítulo 1 Introduzir a engenharia de e explicar a sua importância Responder uma série de perguntas sobre engenharia de Introduzir questões éticas

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Requisitos de Software

Requisitos de Software UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Requisitos de Software Engenharia de Software 2o. Semestre de 2005

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software (Cap 6 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Requisitos funcionais e não funcionais

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications) A boa organização lógica do documento

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

DOCUMENTO DE REQUISITOS

DOCUMENTO DE REQUISITOS DOCUMENTO DE REQUISITOS ID documento: Data: / / Versão : Responsável pelo documento: ID Projeto: HISTÓRICO DE REVISÕES Data de criação/ atualização Descrição da(s) Mudança(s) Ocorrida(s) Autor Versão do

Leia mais

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira

LEVANTAMENTO DE REQUISITOS. Lílian Simão Oliveira LEVANTAMENTO DE REQUISITOS Lílian Simão Oliveira Níveis de erros Fonte: imaster.com um software São as características e funcionalidades que um software tem Engenharia de Requisitos O que é? Quem faz?

Leia mais

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software.

Tópicos da Aula. Que é são requisitos? Tipos de Requisitos. Requisitos Funcionais. Classificação de Requisitos. Requisitos de Software. Engenharia de Software Aula 06 Tópicos da Aula Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 26 Março 2012 Funcionais e não funcionais De usuário e do Engenharia de Estudo

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos

Leia mais

Uma Introdução a Engenharia de Software e Sistemas

Uma Introdução a Engenharia de Software e Sistemas Uma Introdução a Engenharia de Software e Sistemas Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville

Leia mais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais Objetivos de Software Gidevaldo Novais (gidevaldo.vic@ftc.br) Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville

Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV. Adaptado a partir de Gerald Kotonya and Ian Sommerville Análise e Conc epç ão de Sist em as de Inform aç ão,qwurgxomrj(qj GH5HTXLVLWRV Adaptado a partir de Gerald Kotonya and Ian Sommerville 1 Objectivos Introduzir as noções requisitos de sistema e processo

Leia mais

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software Prof. Dr. Juliano Lopes de Oliveira (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

Leia mais

Capítulo 1. Introdução. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1

Capítulo 1. Introdução. 2011 Pearson Prentice Hall. Todos os direitos reservados. slide 1 Capítulo 1 Introdução slide 1 Tópicos apresentados Desenvolvimento profissional de software. O que se entende por engenharia de software. Ética na engenharia de software. Uma breve introdução a questões

Leia mais

Engenharia de Software. Análise de Requisitos de Sistema e de Software. Análise de requisitos

Engenharia de Software. Análise de Requisitos de Sistema e de Software. Análise de requisitos Engenharia de Software Profa. Dra. Lúcia V. L. Filgueiras Profa. Dra. Selma Shin Shimizu Melnikoff Análise de Requisitos de Sistema e de Software Análise de requisitos Sei que você acha que entendeu o

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Requisitos de software

Requisitos de software Requisitos de software Leitura: Sommerville (Cap6) Pressman (Cap5 e 7) SWEBOX - http://www.computer.org/portal/web/swebok 1 Objetivos Compreender os conceitos dos requisitos do usuário e dos requisitos

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

Identificando necessidades e estabelecendo requisitos

Identificando necessidades e estabelecendo requisitos Identificando necessidades e estabelecendo requisitos Resumo A importância de requisitos Diferentes tipos de requisitos Coleta de dados para requisitos Descrição de tarefas: Cenários Casos de uso Casos

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

UNIP Ciência da Computação AES Análise Essencial de Sistemas

UNIP Ciência da Computação AES Análise Essencial de Sistemas 1 Análise Essencial UNIP Ciência da Computação A análise essencial pode ser considerada um refinamento da análise estruturada. O problema existente (ou situação que requer a informatização) é estudado,

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software.

Objetivos. Processos de Software. Tópicos abordados. O processo de software. Modelos genéricos de modelos de processo de software. Processos de Software Objetivos Apresentar os modelos de processo de software Conjunto coerente de atividades para especificar, projetar, implementar e testar s de software Descrever os diferentes modelos

Leia mais

Projeto de Sistemas I

Projeto de Sistemas I Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Algoritmos: Lógica para desenvolvimento de programação de computadores. Autor: José Augusto Manzano. Capítulo 1 Abordagem Contextual

Algoritmos: Lógica para desenvolvimento de programação de computadores. Autor: José Augusto Manzano. Capítulo 1 Abordagem Contextual Algoritmos: Lógica para desenvolvimento de programação de computadores Autor: José Augusto Manzano Capítulo 1 Abordagem Contextual 1.1. Definições Básicas Raciocínio lógico depende de vários fatores para

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás Prof.: Ivon Rodrigues Canedo PUC Goiás Qualidade Subjetiva Não sei o que é mas reconheço quando a vejo Qualidade Baseada no Produto O produto possui algo que produtos similares não têm Qualidade Baseada

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

ANÁLISE E PROJETO DE SISTEMAS

ANÁLISE E PROJETO DE SISTEMAS UFU Universidade Federal de Uberlândia ANÁLISE E PROJETO DE SISTEMAS INTRODUÇÃO A ENGENHARIA DE SOFTWARE Professora: Fabíola Gonçalves. AGENDA Introdução à Engenharia de Software Características do Software

Leia mais

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE Prof. Msc. Hélio Esperidião O QUE É UM ALGORITMO? É qualquer procedimento computacional bem definido que informa algum valor ou conjunto de valores como entrada

Leia mais

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos)

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Engenharia, Levantamento, Elicitação, Gerenciamento Fernando Pedrosa fpedrosa@gmail.com 1 2 Área da Engenharia

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais

Engenharia de Requisitos. Aécio Costa

Engenharia de Requisitos. Aécio Costa Aécio Costa Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir os seus objetivos. (PFLEEGER, 2004) Um requisito é algo que o sistema é capaz

Leia mais

Ricardo Schäffer. (Palavras-chave: EEMUA, HCI, SCADA) HCI. Apresentação

Ricardo Schäffer. (Palavras-chave: EEMUA, HCI, SCADA) HCI. Apresentação EEMUA 201 GUIA DE DESIGN PARA INTERFACES HUMANAS OPERACIONAIS Versão adaptada do guia original publicado pela Associação de Usuários de Equipamentos e Materiais de Engenharia. Ricardo Schäffer Resumo -

Leia mais

Projeto Estruturado de Sistema

Projeto Estruturado de Sistema Projeto Estruturado de Sistema Sumário 1. FASES NO DESENVOLVIMENTO E MANUTENÇÃO DO SOFTWARE... 2 1.1 Síntese das Fases... 2 1.2 Controle de Qualidade... 3 2. ATIVIDADES DAS FASES... 3 2.1 Fase 0 - Anteprojeto...

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO

CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO CONHECENDO E CONCEITUANDO SISTEMAS DE INFORMAÇÃO Franco Vieira Sampaio 1 Atualmente a informática está cada vez mais inserida no dia a dia das empresas, porém, no início armazenavam-se os dados em folhas,

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Roteiro Análise de requisitos Definição de requisitos do sistema Requisitos Funcionais Requisitos Não Funcionais Exercício Análise de Requisitos Análise de Requisitos É o 1º passo

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Análise Orientada a Objetos

Análise Orientada a Objetos Análise Orientada a Objetos Breve Histórico: Fim da década de 80: amadurecimento da Orientação a Objeto Década de 1990: diversas proposições a partir de diversos autores, como Booch, Rumbaugh e Jacobson.

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Tópicos. Engenharia de Software: Uma Visão Geral

Tópicos. Engenharia de Software: Uma Visão Geral Tópicos 2 3 Engenharia de Software: Uma Visão Geral SCE 186 - Engenharia de Software Profs. José Carlos Maldonado e Elisa Yumi Nakagawa 2 o semestre de 2002 A importância do Software Software Aplicações

Leia mais

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos:

Sistemas Operacionais Cap 3 Estruturas de Sistemas Operacionais. Podemos analisar um sistema operacional sob diversos aspectos: Estruturas de Sistemas Operacionais Podemos analisar um sistema operacional sob diversos aspectos: Os serviços que o sistema operacional oferece. A interface que o sistema operacional torna disponível

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Construindo Softwares com Qualidade e Rapidez Usando ICONIX

Construindo Softwares com Qualidade e Rapidez Usando ICONIX Construindo Softwares com Qualidade e Rapidez Usando ICONIX José Anízio Maia Este tutorial aborda as principais fases de construção de softwares de forma rápida e com qualidade através do processo de desenvolvimento

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

Guia do Cúram Verification

Guia do Cúram Verification IBM Cúram Social Program Management Guia do Cúram Verification Versão 6.0.5 IBM Cúram Social Program Management Guia do Cúram Verification Versão 6.0.5 Nota Antes de usar essas informações e o produto

Leia mais

Requisitos. Sistemas de Informações

Requisitos. Sistemas de Informações Requisitos Sistemas de Informações Definindo o Sucesso do Software Clientes satisfeitos Eles estão satisfeitos quando você: Atende às expectativas Entrega no prazo Entrega no orçamento O Sucesso começa

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I UNIVERSIDADE FEDERAL DO MATO GROSSO ENGENHARIA DE SOFTWARE I Introdução à Engenharia de Software: Motivação, Histórico, Conceitos, Elementos de ES e Mitos do Software AULA 1 Profª MSc. MICHELLE DE OLIVEIRA

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Gerenciamento de Projetos Modulo IV Integração

Gerenciamento de Projetos Modulo IV Integração Gerenciamento de Projetos Modulo IV Integração Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases

Modelagem de Requisitos com Casos de Uso. Descrever em detalhe a técnica de Modelagem com Use Cases Engenharia de Software Modelagem de Requisitos com Casos de Uso 1 Objetivos Descrever em detalhe a técnica de Modelagem com Use Cases 2 1 Use Case É uma forma específica de uso do sistema através da execução

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

Fundamentos de Sistemas Computacionais Introdução

Fundamentos de Sistemas Computacionais Introdução Fundamentos de Sistemas Computacionais Introdução Prof. Eduardo Alchieri Sistema Computacional Hardware Software Usuários Um ou mais processadores, memória, discos, impressoras, teclado, mouse, monitor,

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

44 Summit Road, Suite 101 Riverside, CT 06878 (800) 573-4756 (203) 698-9323

44 Summit Road, Suite 101 Riverside, CT 06878 (800) 573-4756 (203) 698-9323 oferece consistência de suporte entre grupos de desenvolvimento Michel Vrinat, Diretor de Programa, PLM, CAE/Europa; Don Brown, Presidente Medição do desafio confrontando o desenvolvimento do produto A

Leia mais

Engenharia de Requisitos

Engenharia de Requisitos UFES - Universidade Federal do Espírito Santo Engenharia de Requisitos Notas de Aula E-mail: falbo@inf.ufes.br 2012 Sumário Capítulo 1 - Introdução 1 1.1 Desenvolvimento de Software e Engenharia de Requisitos

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 2 - ANÁLISE DE REQUISITOS DE SOFTWARE APLICATIVO 1. INTRODUÇÃO Entender os requisitos de um problema está entre as tarefas mais difíceis na construção de um software. Na maioria das vezes o cliente

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

Modelo Funcional Essencial

Modelo Funcional Essencial Modelo Funcional Essencial Análise e Projeto - 1 Tem como objetivo definir o que o sistema deve fazer, ou seja, as funções que deve realizar para atender seus usuários. Na análise essencial fazemos essa

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

Fundamentos de Automação. Controladores

Fundamentos de Automação. Controladores Ministério da educação - MEC Secretaria de Educação Profissional e Técnica SETEC Instituto Federal de Educação Ciência e Tecnologia do Rio Grande do Sul Campus Rio Grande Fundamentos de Automação Controladores

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais