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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

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

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

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

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

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

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

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

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

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

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

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

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

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 à Engenharia de Software. Profª Jocelma Rios

Introdução à Engenharia de Software. Profª Jocelma Rios Introdução à Engenharia de Software Profª Jocelma Rios Jun/2013 O que pretendemos Apresentar os conceitos básicos de engenharia de software e as disciplinas que a compõem Apresentar as questões mais relevantes

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

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

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

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

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

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

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

Módulo 4: Gerenciamento de Dados

Módulo 4: Gerenciamento de Dados Módulo 4: Gerenciamento de Dados 1 1. CONCEITOS Os dados são um recurso organizacional decisivo que precisa ser administrado como outros importantes ativos das empresas. A maioria das organizações não

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

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA

Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA QUESTÃO RESPOSTA QUESTÃO RESPOSTA ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008 3º PERÍODO - 5º MÓDULO AVALIAÇÃO MP1 DATA 05/03/2009 ENGENHARIA DE SOFTWARE Dados de identificação do Acadêmico: Nome: Login: CA: Cidade: UF CARTÃO RESPOSTA

Leia mais

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

Engenharia de Software II

Engenharia de Software II Engenharia de Software II Aula 27 http://www.ic.uff.br/~bianca/engsoft2/ Aula 27-26/07/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software O que é a engenharia de software É um conjunto integrado de métodos e ferramentas utilizadas para especificar, projetar, implementar e manter um sistema. Método É uma prescrição

Leia mais

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1

QUALIDADE DE SOFTWARE. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 QUALIDADE DE SOFTWARE Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 27 Slide 1 Objetivos Apresentar o processo de gerenciamento de qualidade e as atividades centrais da garantia de

Leia mais

Módulo 5 Interpretação da norma NBR ISO 19011:2002 requisitos: 7, 7.1, 7.2, 7.3, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.4, 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.

Módulo 5 Interpretação da norma NBR ISO 19011:2002 requisitos: 7, 7.1, 7.2, 7.3, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.4, 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7. Módulo 5 Interpretação da norma NBR ISO 19011:2002 requisitos: 7, 7.1, 7.2, 7.3, 7.3.1, 7.3.2, 7.3.3, 7.3.4, 7.4, 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.5, 7.5.1, 7.5.2, 7.6, 7.6.1, 7.6.2 Exercícios 7 Competência

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

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

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

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

Modelagem do Processo de Negócio

Modelagem do Processo de Negócio Análise e Projeto 1 Modelagem do Processo de Negócio Modelos de processos de negócios descrevem as diferentes atividades que, quando combinados, oferecem suporte a um processo de negócio. Processos de

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

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

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

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

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo 4 PROCESSOS Os primeiros sistemas operacionais permitiam que apenas um processo fosse executado por vez. Dessa maneira, este processo tinha todo o sistema computacional a sua disposição. Os atuais sistemas

Leia mais

Feature-Driven Development

Feature-Driven Development FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por

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

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

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

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Construção e Implantação de Software II - Unidade 3- Estratégias Para Testes de Software. Prof. Pasteur Ottoni de Miranda Junior

Construção e Implantação de Software II - Unidade 3- Estratégias Para Testes de Software. Prof. Pasteur Ottoni de Miranda Junior Construção e Implantação de Software II - Unidade 3- Estratégias Para Testes de Software Prof. Pasteur Ottoni de Miranda Junior 1 1-Estratégia Global 1.1-Visão Global de Estratégias Para Teste A estratégia

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

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

Teste de software. Definição

Teste de software. Definição Definição O teste é destinado a mostrar que um programa faz o que é proposto a fazer e para descobrir os defeitos do programa antes do uso. Quando se testa o software, o programa é executado usando dados

Leia mais

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

Processos de Software. 2007 by Pearson Education Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Processos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 4 Slide 1 Objetivos Apresentar modelos de processos de software Descrever três modelos genéricos de processo e quando

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

ABNT NBR ISO/IEC 27002:2005

ABNT NBR ISO/IEC 27002:2005 ABNT NBR ISO/IEC 27002:2005 Código de prática para a gestão da segurança da informação A partir de 2007, a nova edição da ISO/IEC 17799 será incorporada ao novo esquema de numeração como ISO/IEC 27002.

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

SISTEMA DE COMUNICAÇÃO DO SISTEMA INTEGRADO DE ADMINISTRAÇÃO DE SERVIÇOS GERAIS - COMUNICA. Manual do Usuário

SISTEMA DE COMUNICAÇÃO DO SISTEMA INTEGRADO DE ADMINISTRAÇÃO DE SERVIÇOS GERAIS - COMUNICA. Manual do Usuário SISTEMA DE COMUNICAÇÃO DO SISTEMA INTEGRADO DE ADMINISTRAÇÃO DE SERVIÇOS GERAIS - COMUNICA Manual do Usuário Título SISTEMA DE COMUNICAÇÃO DO SISTEMA INTEGRADO DE ADMINISTRAÇÃO DE SERVIÇOS GERAIS - COMUNICA

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

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

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

Requisitos do usuário, do sistema e do software [Sommerville, 2004]

Requisitos do usuário, do sistema e do software [Sommerville, 2004] Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

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

APOO Análise e Projeto Orientado a Objetos. Requisitos

APOO Análise e Projeto Orientado a Objetos. Requisitos + APOO Análise e Projeto Orientado a Objetos Requisitos Requisitos 2 n Segundo Larman: n São capacidades e condições às quais o sistema e em termos mais amplos, o projeto deve atender n Não são apenas

Leia mais

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga

DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil. Profª Esp.: Maysa de Moura Gonzaga DISCIPLINA ENGENHARIA DE SOFTWARE Aula 03 Processo Unificado e Desenvolvimento Ágil Profª Esp.: Maysa de Moura Gonzaga 2º Semestre / 2011 O Processo Unificado dos autores Ivar Jacobson, Grady Booch e James

Leia mais

ERGONOMIA. Prof. Ruy Alexandre Generoso

ERGONOMIA. Prof. Ruy Alexandre Generoso ERGONOMIA Prof. Ruy Alexandre Generoso Ergonomia de Software - Definição É a ciência que estuda o conforto, a utilização, a organização e a documentação do software. Tem como objetivo facilitar e otimizar

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

Políticas de Segurança da Informação. Aécio Costa

Políticas de Segurança da Informação. Aécio Costa Aécio Costa A segurança da informação é obtida a partir da implementação de um conjunto de controles adequados, incluindo políticas, processos, procedimentos, estruturas organizacionais e funções de software

Leia mais

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de SCE186-ENGENHARIA DE SOFTWARE Módulo 1 Atividades da Engenharia de GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br 2003 DEFINIÇÃO CONSTRUÇÃO SOFTWARE PRODUTO MANUTENÇÃO

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

Gerenciamento do escopo

Gerenciamento do escopo Gerenciamento do escopo Gerenciamento do escopo Escopo pode ser definido como a soma dos produtos de um projeto, bem como a descrição de seus requisitos. O momento de definir o escopo é a hora em que o

Leia mais

Prof. Antonio Almeida de Barros Jr. Prof. Antonio Almeida de Barros Junior

Prof. Antonio Almeida de Barros Jr. Prof. Antonio Almeida de Barros Junior Prof. Antonio Almeida de Barros Jr. Introdução Dados Informações Banco de Dados Conceitos Básicos em Bancos de Dados Definição BD - Banco de Dados SGBD - Sistema de Gerenciamento de BD Programa de Aplicação

Leia mais