Aula01 - Processo de Desenvolvimento de Software

Algumas perguntas iniciais...
O que software? O que Engenharia de Software? O que um Processo de Desenvolvimento de Software?
Processo de Desenvolvimento de Software
Quais so os atributos de um bom software?
Ricardo Choren choren@ime.eb.br
08/02/2011
Ricardo Choren 2011/IME
O que software?
Programas de computador e sua documentao respectiva, tais como modelos de anlise, manuais do usurio, etc. Produtos de software podem ser desenvolvidos para um cliente particular ou para o mercado em geral
Genricos: desenvolvidos para serem vendidos (usados) para uma variedade de clientes (p. ex. MS Office) Customizados: desenvolvidos para um cliente especfico, de acordo com uma especificao fornecida por ele
O que Engenharia de Software?

Engenharia de Software uma disciplina de engenharia que se preocupa com todos os aspectos da produo de software Se vale de
Abordagens sistemticas e organizadas Ferramentas e tcnicas apropriadas
Um novo software pode ser criado a partir do zero, da configurao de software genrico ou do reuso de software existente
08/02/2011
08/02/2011
O que um PDS?
Conjunto de atividades com o objetivo de desenvolver ou evoluir um software Atividades genricas em todos os processos de desenvolvimento de software incluem
Especificao: o que o sistema deve fazer e as suas restries Desenvolvimento: produo do sistema de software Validao: verificao de que o software o que o cliente espera Evoluo: alterar o software em resposta a novas demandas dos clientes
Quais so os atributos de um bom software?

Um software deve entregar a funcionalidade e a performance requerida para o usurio, alm de ser manutenvel, confivel e aceitvel Facilidade de manuteno
O software deve ser escrito de modo que possa evoluir para atender s necessidades de mudana dos clientes
Confiana
Um software confivel (confiabilidade, proteo, segurana) no deve causar danos fsicos ou econmicos no caso de falha no sistema
Eficincia
O software no deve desperdiar os recursos do sistema, como memria e processador
Usabilidade
O software deve ser usvel, sem um esforo excessivo, pelo tipo de usurio para o qual ele foi projetado Interface com o usurio e documentao adequados
08/02/2011
08/02/2011
Atividades genricas de um PDS

Especificao de software Desenvolvimento (projeto e implementao) de software Validao de software Evoluo de software
Especificao de software
Processo para compreender e definir quais servios so necessrios e identificar as restries de operao e de desenvolvimento do software Processo de engenharia de requisitos
Estudo de viabilidade Levantamento e anlise de requisitos Especificao de requisitos Validao de requisitos
08/02/2011
08/02/2011
Desenvolvimento de software
Processo de converso de uma especificao de software em um software executvel Envolve processos de projeto e implementao Projeto de software
Projetar uma estrutura de software que realiza a especificao
Atividades do projeto de software
Projeto arquitetural
Os subsistemas constituintes do software e seus relacionamentos so identificados e documentados
Especificao abstrata
Para cada subsistema, so produzidas uma especificao abstrata dos servios e das restries sob as quais deve operar
Implementao
Traduzir esta estrutura para um programa executvel
Projeto da interface
Para cada subsistema, projetada e documentada a interface com outros subsistemas
Projeto de componentes
Os servios e as interfaces de cada subsistema so projetados
08/02/2011
08/02/2011
Atividades do projeto de software (cont.)
Projeto da estrutura de dados
As estruturas de dados usadas em cada subsistema so projetadas detalhadamente
Validao de software
Verificao e validao procura mostrar que um sistema est conforme sua especificao e que alcana os requisitos do cliente Envolve processos de inspeo (verificao esttica) e testes (verificao dinmica) Estgios do processo de teste
Teste de unidade (componente) Teste de integrao (sistema) Teste de aceitao
Projeto dos algoritmos

Os algoritmos que implementaro os servios dos subsistemas so projetados detalhadamente
08/02/2011
08/02/2011
Evoluo de software
Software inerentemente flexvel e pode sofrer mudanas
Com as mudanas de requisitos devido mudanas das circunstncias do negcio, o software que d suporte ao negcio tambm tem que evoluir e mudar
Tipos de manuteno
Reparar defeitos Adaptar software Adicionar / modificar funcionalidades
Requisitos de Software
Processo de manuteno
Solicitao de mudana Anlise de impacto Planejamento de verso Implementao de mudana Liberao do sistema
08/02/2011
08/02/2011
O que um requisito?
Um requisitos uma descrio de
Servios (funcionalidades) Restries (de operao e de desenvolvimento)
A importncia dos requisitos

A parte individual mais difcil da construo de um sistema de software decidir o que construir
Nenhuma parte do trabalho danifica tanto o sistema resultante se for feita de forma incorreta Nenhuma outra parte mais difcil de se consertar depois
A descrio de um requisitos pode variar variar de uma descrio abstrata (de alto-nvel) de um servio ou de uma restrio do sistema at uma especificao matemtica detalhada
Quanto mais tarde no processo de desenvolvimento um defeito for detectado, maior ser o custo para consert-lo
Estgio do PDS e custo relativo de conserto de um defeito
Requisitos 1 Anlise e projeto 5 Codificao 10 Teste de aceitao 50 Manuteno 200
08/02/2011
08/02/2011
Nveis de abstrao
O que o cliente quer / o que o sistema deve fazer
Nveis de requisitos
Requisitos de usurio (nvel: problema)
Define os servios que o sistema deve oferecer e as suas restries operacionais
Necessidades
Viso
Problema Soluo
Escritos para serem lidos pelos clientes
Requisitos de sistema (nvel: soluo)
Caractersticas (requisitos de alto nvel) Requisitos detalhados do software
Mostra descries detalhadas das funcionalidades do sistema Define o que deve ser projetado/implementado e deve fazer parte do contrato
Especificao Detalhada
08/02/2011
08/02/2011
Tipos de requisitos de sistema

Requisitos funcionais
Funcionalidades disponibilizadas pelo software, de modo a capacitar os usurios a executar suas tarefas e satisfazer s necessidades do negcio So aes que o produto deve realizar de modo a fornecer funcionalidades teis para seus usurios
Tipos de requisito de sistema

Requisitos funcionais de usurio podem ser em alto-nvel Requisitos funcionais de sistema devem descrever detalhadamente os servios do sistema Requisitos no-funcionais costumam ser mais crticos que os funcionais.
Se os requisitos no-funcionais no forem alcanados, o sistema intil
Requisitos no-funcionais
So propriedades ou qualidades que o produto deve possuir Em sua maioria, no expressam nenhuma funo a ser realizada pelo software, mas sim necessidades e restries que o mesmo deve satisfazer
08/02/2011
08/02/2011
Classificao de requisitos no-funcionais

Requisitos de produto
Requisitos que especificam que um produto entregue deve se comportar de uma determinada maneira, por exemplo, tempo de execuo (desempenho) e confiabilidade
Classificao de requisitos no-funcionais

Exemplos
Requisito de produto
O sistema deve ser capaz de responder a, pelo menos, 300 usurios simultaneamente
Requisitos organizacionais
Requisitos que so conseqncia de polticas ou procedimentos organizacionais, por exemplo, padres utilizados e modo de implementao
Requisito organizacional
O processo de desenvolvimento do sistema e os documentos a serem entregues devem estar conformes ao modelo X
Requisito externo
O sistema no dever compartilhar informaes pessoais dos clientes a no ser seu nome e seu nmero de referncia para os operadores do sistema
Requisitos externos
Requisitos que vm de fatores que so externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade e requisitos legais
08/02/2011
08/02/2011
Impreciso dos requisitos

Problemas podem ocorrer quando requisitos no so claramente definidos
Requisitos ambguos podem ser interpretados de forma diferentes por clientes e desenvolvedores
Impreciso dos requisitos

Conflitos entre requisitos no-funcionais em sistemas grandes so muito comuns Exemplo: sistema da nave espacial
Para minimizar o peso da nave, o nmero de chips do sistema deve ser minimizado Para minimizar o consumo de energia, chips de baixo consumo devem ser usados No entanto, usar chips de baixo consumo pode acarretar no uso de um nmero maior de chips. Qual o requisito mais crtico?
Em princpio, requisitos devem ser completos e consistentes

Completos
Devem conter a descrio de todas as necessidades requeridas
Consistentes
No deve haver conflitos ou contradies nas descries das funcionalidades do sistema
Na prtica, pode ser impossvel gerar um documento de requisitos completo e consistente
08/02/2011
08/02/2011
Refinamento de requisitos
Refinamento de requisitos funcionais
Definir
Cada entrada e sada Cada validao Cada transformao Os comportamento normais e alternativos Os comportamentos em cada exceo
Refinamento de requisitos no-funcionais
Requisitos no-funcionais podem ser difceis de se refinar precisamente e, conforme dito anteriormente, requisitos imprecisos so difceis de se verificar
Definio de objetivos e verificaes

Objetivo
Uma inteno genrica do usurio, como facilidade de uso
E a Interface com o Usurio?

Nvel mais concreto observado pelo usurio. Deve ser validada antes de se investir grande esforo na construo
Requisito no-funcional verificvel

Um refinamento que usa alguma medida que pode ser objetivamente testada
08/02/2011
08/02/2011
Exemplo de refinamento de requisito no-funcional
Um objetivo do sistema
O sistema deve ser fcil de ser usado por controladores experientes e deve ser organizado de forma a minimizar os erros dos usurios Requisito no-funcional de usabilidade
Requisitos e o desenvolvimento
Requisitos devem mostrar o que o sistema deve fazer e o projeto deve mostrar como o sistema deve fazer Alguns detalhes
A arquitetura do software deve ser diretamente derivada de seus requisitos O software pode ter que inter-operar com outros sistemas, isto cria novos requisitos que tero impacto no projeto
Um requisito no-funcional verificvel

Controladores experientes devem ser capazes de usar o sistema como um todo depois de duas horas de treinamento Depois deste treinamento o nmero mdio de erros cometidos por controladores experientes no deve exceder dois por dia
08/02/2011
08/02/2011
Documentando requisitos
Requisitos podem ser documentados de diversas maneiras As maneiras mais usuais de se documentar requisitos so
Linguagem natural Formulrios Modelagem grfica
Linguagem natural
Faz uso de texto em lngua corrente para descrever os requisitos de sistema Problemas
Ambigidade
Quem escreve e quem l o documento podem interpret-los de formas diferentes
Muita flexibilidade
Uma mesma coisa pode ser descrita de diversas formas
Falta de modularizao
A estrutura da linguagem natural no a melhor para se descrever requisitos
08/02/2011
08/02/2011
Formulrios
Faz uso de linguagem natural estruturada para descrever os requisitos de sistema Campos usuais
Definio da funo ou entidade Descrio das entradas e de onde elas vm Descrio das sadas e para onde elas vo Indicao de que outras entidades so necessrias Pr e ps-condies (onde aplicveis) Os efeitos colaterais da funo (se existirem)
Modelagem grfica
Modelos grficos so interessantes quando se precisa mostrar mudanas de estado ou seqncia de aes Exemplos
Diagrama de Fluxo de Dados Modelo de Casos de Uso
08/02/2011
08/02/2011
Processo de engenharia de requisitos (ER)

Os processos usados pela engenharia de requisitos variam dependendo do domnio da aplicao, das pessoas envolvidas e da organizao que est desenvolvendo os requisitos
Processo de Engenharia de Requisitos
Entretanto, existe um conjunto genrico de atividades comuns a todos os processos

Estudo de viabilidade Levantamento e anlise de requisitos Especificao de requisitos Validao de requisitos Gerncia de requisitos
08/02/2011
08/02/2011
Modelo do processo de ER
A ER um processo iterativo
Necessidades Informais Especificao da Soluo

Estudo de Viabilidade Levantamento e Anlise de Requisitos Especificao dos Requisitos Verificao e Validao dos Requisitos
Rejeitada Nova Especificao
Gerncia dos Requisitos
Rejeitada
Clientes
Nova Especificao Aprovada
Desenvolvedores
08/02/2011
08/02/2011
Estudo de viabilidade
Um estudo de viabilidade deve decidir se vale a pena desenvolver o sistema Um estudo focado que verifica
Se o sistema contribui para os objetivos organizacionais Se o sistema pode ser desenvolvido com a tecnologia e o oramento disponveis Se o sistema pode ser integrado com outros sistemas em funcionamento
Estudo de viabilidade
Fazendo um estudo de viabilidade
Baseado na coleta e avaliao de informao e no levantamento e anlise de riscos do projeto Procurar respostas com as pessoas da organizao para perguntas do tipo
Quais so os problemas existentes? De que forma o/um sistema ajudaria a resolver este problema? Que facilidades devem ser oferecidas pelo sistema proposto? Qual a tecnologia e as competncias necessrias para desenvolver o sistema? E se o sistema no for desenvolvido?
08/02/2011
08/02/2011
Levantamento e anlise de requisitos

Entender as atividades, os conceitos, os problemas, a cultura e a linguagem dos usurios para construir sistemas que atendam s suas necessidades
Envolve pessoal tcnico trabalhando com clientes para obter informaes sobre o domnio do problema, os servios que o sistema deve oferecer e as restries operacionais do sistema

Processo de levantamento e anlise de requisitos
Descoberta de requisitos
Interao com os interessados para descobrir seus requisitos. Requisitos de domnio tambm devem ser descobertos
Classificao e organizao dos requisitos

Agrupar requisitos relacionados e organiz-los
Priorizao e negociao
Priorizar requisitos e resolver conflitos existentes
Documentao dos requisitos

Os requisitos so documentados
08/02/2011
08/02/2011

Tcnicas para descoberta de requisitos
Entrevistas Brainstorming / JAD Observao (ou etnografia) Outros... Baseado no seu processo

Tcnicas para descoberta de requisitos :: Entrevista
Envolve consultar os clientes para entender os servios e as restries do sistema a ser desenvolvido
Entrevistadores tm que estar abertos e desejosos de ouvir os interessados No devem ter idias pr-concebidas sobre os requisitos Entrevistadores devem procurar fazer com que os interessados interajam e, assim, discutam os requisitos No devem apenas perguntar "o que voc quer do sistema"
08/02/2011
08/02/2011

Fase Pr-reunio
Identificar os entrevistados
Poder de deciso Perfis necessrios Muitos usurios => amostragem

Fase de Reunio
Dinmica
Abra a reunio apresentando a equipe e os objetivos da reunio Pergunte Oua Recapitule Confirme o entendimento sobre cada tema com uma sntese: Em resumo, foi definido que ... Respeite o tempo combinado
Providenciar recursos
Agendar data/horrio e durao Agendar local apropriado com os recursos necessrios
Registro
No tente anotar todos os detalhes durante a entrevista. Use um gravador, se possvel, ou o apoio de outro profissional Registre definies, pendncias e atividades a serem realizadas
Elaborar roteiro para reunio

Definir objetivos e assuntos Elaborar pauta de perguntas
Estudar os assuntos a serem abordados

Acesso prvio a documentao, sites, outros sistemas. Solicite exemplos de formulrios, relatrios, situaes, ...
Encerramento
Abra um canal para comunicao posterior com os entrevistados (nome telefone email) Conclua a reunio, informando os prximos passos
Notificar os participantes
08/02/2011
08/02/2011

Fase Ps-reunio
Transcrever a entrevista, imediatamente aps a sua realizao, para uma ata de reunio Revisar e aprovar a ata Acompanhar pendncias e atividades relatadas Consolidar informaes de vrias entrevistas

Erros comuns
Induo
Voc precisa de uma tela maior, no isso?
Perguntas de controle / interrupo

O que voc est falando interessante, mas podemos voltar s minhas perguntas?
Perguntas muito longas ou muito complexas

Eu tenho uma questo que se divide em trs partes, a primeira...
08/02/2011
08/02/2011

Tcnicas para descoberta de requisitos :: Brainstorming
Muito til quando existem diversos interessados no projeto dividido em duas etapas
Na primeira, anota-se todas as idias que surgirem, sem que sejam questionadas
Neste momento o que importa mais a quantidade, no deixe de anotar nada

Fase de Preparao
Inclui a seleo dos participantes e do coordenador da sesso, suas convocaes e preparao de uma sala para o encontro Os participantes so clientes, usurios, engenheiros de requisitos, desenvolvedores e, se necessrio, pessoas com expertise no negcio objeto do projeto
Na segunda etapa, debate-se com o grupo para ir refinando as idias apresentadas anteriormente
08/02/2011
08/02/2011

Fase de Gerao
O coordenador abre a sesso expondo um enunciado geral do problema a tratar, que serve de base para que as idias sejam geradas Os participantes apresentam novas idias sobre o problema, ordenadamente ou aleatoriamente, conforme determinado pelo coordenador da sesso Esse processo contnuo at que o coordenador decida parar
No se est gerando mais idias suficientes Se deva dar continuidade posteriormente reunio J se obteve um nmero de idias suficientes para se passar fase seguinte

Fase de Gerao
Nesta fase importante se observar as seguintes regras
Crticas s idias so proibidas. O objetivo criar um ambiente em que os participantes se sintam livres para formular qualquer idia Devem ser fomentadas idias mais avanadas, ainda que no sejam factveis, estimulando os demais participantes a explorar solues mais criativas Deve ser gerado um grande nmero de idias, j que quanto mais idias se apresentem maior a probabilidade de que idias melhores sejam geradas Deve-se estimular os participantes a combinar ou completar as idias de outros As idias devem ser registradas de forma que permaneam visveis durante a discusso
08/02/2011
08/02/2011

Fase de Consolidao
Nesta fase deve-se organizar e avaliar as idias geradas durante a fase anterior, seguindo os seguintes passos
Revisar idias. Agrupar as idias similares, unificando-as em um s enunciado, se possvel Descartar idias. As idias consideradas extremamente avanadas ou fora do contexto devem ser descartadas pelo grupo Priorizar idias. As idias restantes devem ser priorizadas, identificando as absolutamente essenciais, as que devem ser incorporadas soluo e aquelas que devem ficar para uma prxima verso do sistema

Fase de Documentao
Depois da sesso o coordenador produz a documentao oportuna contendo as idias priorizadas e comentrios gerados durante a consolidao
08/02/2011
08/02/2011

Tcnicas para descoberta de requisitos :: JAD
Joint Application Design (ou Development) Tcnica similar ao brainstorming, mas com intenso apoio visual
Desenvolvida pela IBM em 1977

Fase de Definio
Seleo dos participantes Programao da sesso JAD
Fases do JAD
Definio do projeto JAD Pesquisa Preparao Sesso JAD Documento final
Fase de Pesquisa
Familiarizao com as reas de negcio e com sistemas Recolhimento de informaes preliminares Preparao da agenda da sesso JAD
Fase de Preparao
Elaborao do documento de trabalho Treinamento do documentador e estabelecimento do protocolo de comunicao Preparao das facilidades visuais e da sala da reunio
08/02/2011
08/02/2011

Fase de Seo JAD
Abertura da sesso
Apresentao pessoal, itens administrativos Apresentao dos objetivos da sesso, agenda e documento de trabalho Apresentao das regras da sesso

Fase de Documento Final
Elaborao do documento final Reviso do documento final Realizao da reunio de reviso Aprovao do documento final Distribuio do documento final
Viso geral do negcio Discutir as premissas coletadas Identificar e discutir os tpicos do documento de trabalho, procurando um consenso nas decises
Para cada tpico a ser validado de cada rodada, o facilitador Apresenta o tpico Transfere a palavra a cada um dos participantes da sesso, solicitando que se manifeste sobre o tpico
Avaliao da sesso JAD Fechamento da sesso JAD

08/02/2011 Ricardo Choren 2011/IME 08/02/2011 Ricardo Choren 2011/IME

Tcnicas para descoberta de requisitos :: Observao
As pessoas no tm que ou tm dificuldades de explicar seu trabalho Alguns fatores organizacionais s so levantados por observao Requisitos devem ser derivados a partir da forma como as pessoas realmente trabalham em vez da forma como o processo organizacional sugere que estas trabalhem Alguns requisitos so levantados a partir da cooperao entre as atividades das pessoas

Tcnicas para descoberta de requisitos :: Observao
Atravs de uma observao direta das atividades realizadas durante um perodo de trabalho de um funcionrio possvel encontrar requisitos que no seriam levantados usando tcnicas convencionais
Pode ser acompanhada de registros udio/vdeo Nesta tcnica assume-se que o representante do cliente observado desempenha as suas funes "corretamente", pelo que convm ter algum cuidado na escolha do mesmo
08/02/2011
08/02/2011

Depois de se descobrir os requisitos, preciso fazer uma anlise e uma negociao dos requisitos
Analisar o que foi levantado
Registrar os problemas / necessidades Modelar o entendimento sobre o contexto (dados, processos, envolvidos, locais, eventos/ciclos temporais) Entender a importncia relativa das necessidades Identificar conflitos, inconsistncias, omisses Propor e negociar alternativas de soluo
Especificao de requisitos
Documentar os requisitos levantados, analisados e priorizados Usar documento padronizado pelo processo
Serve de comunicao entre a equipe de desenvolvimento e os clientes DFDs, Modelos de Casos de Uso, etc.
A anlise distribui os requisitos em categorias, explora as relaes entre eles, e classifica a importncia de cada um dos requisitos (priorizao)
08/02/2011
08/02/2011
10
Especificao de requisitos
Especificaes suplementares
Regras de negcio Arquitetura Padro de interfaces
Usurio, hardware, software e comunicao
Validao de requisitos
Se preocupa em demonstrar que os requisitos definem o sistema que o cliente realmente quer
Estamos construindo o produto correto? Estamos construindo o produto da forma correta?
A especificao examinada de forma a tentar assegurar que os requisitos foram definidos sem ambigidades, inconsistncias ou omisses, e que todos os defeitos foram detectados e corrigidos Inspeo e utilizao de checklists
08/02/2011
08/02/2011
Deve-se validar os requisitos quanto a
Validade
O sistema oferece as funes que melhor atendem s necessidades dos usurios?
Deve-se validar os requisitos quanto a (cont.)
Verificao
O requisito realisticamente testvel?
Compreensibilidade
O requisito foi corretamente entendido?
Consistncia
Existem requisitos conflitantes?
Rastreabilidade
A origem do requisito est claramente definida?
Completude
Todas as funes requeridas pelo cliente esto includas?
Adaptabilidade
Um requisito pode mudar sem afetar outros requisitos?
Realismo
Os requisitos podem ser implementados com as habilidades e o oramento disponveis?
08/02/2011
08/02/2011
Tcnicas para validao de requisitos Reviso (inspeo) de requisitos
Anlise sistemtica (manual) dos requisitos
Gerncia de requisitos
Define uma abordagem sistemtica para levantar, organizar e documentar as modificaes nos requisitos executada em paralelo durante todo o processo de desenvolvimento Captura de informaes de apoio gerncia do projeto
Importncia Risco Release previsto ...
Desenvolvimento de prottipos
Usar um modelo executvel do sistema para checar seus requisitos
Gerao de casos de teste

Desenvolvimento de testes para verificao de requisitos
Apoio na avaliao do impacto das mudanas
08/02/2011
08/02/2011
11
Durante o processo de engenharia de requisitos, deve-se planejar Identificao dos requisitos
Como os requisitos so individualmente identificados
Rastreabilidade
A rastreabilidade se preocupa com o relacionamento entre os requisitos, suas fontes e o projeto do sistema Rastreabilidade da fonte
Ligaes entre os requisitos e os interessados que os propuseram
Poltica de rastreabilidade
A quantidade de informao sobre os requisitos que deve ser mantida
Rastreabilidade entre requisitos

Ligaes entre requisitos dependentes
Rastreabilidade do projeto
Ligaes entre os requisitos e o projeto/implementao do sistema
Processo de gerncia de mudanas

O processo que deve ser seguido quando uma mudana em um requisito ocorrer
08/02/2011
08/02/2011
Processo de gerncia de mudanas
Deve ser aplicada a todas as mudanas nos requisitos Estgios principais
Anlise do problema
Discutir o problema com o requisito e propor a mudana
Anlise e custo da mudana

Avaliar os efeitos da mudana em outros requisitos
Implementao da mudana
Modificar o documento de requisitos e os demais documentos relacionados
08/02/2011
08/02/2011
12

Aula01 - Processo de Desenvolvimento de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula01 - Processo de Desenvolvimento de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Algumas perguntas iniciais...

O que software? O que Engenharia de Software? O que um Processo de Desenvolvimento de Software?

Processo de Desenvolvimento de Software

Quais so os atributos de um bom software?

Ricardo Choren choren@ime.eb.br

Ricardo Choren 2011/IME

O que Engenharia de Software?

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Quais so os atributos de um bom software?

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Atividades genricas de um PDS

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Projeto dos algoritmos

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

A importncia dos requisitos

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Escritos para serem lidos pelos clientes

Requisitos de sistema (nvel: soluo)

Caractersticas (requisitos de alto nvel) Requisitos detalhados do software

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Tipos de requisitos de sistema

Tipos de requisito de sistema

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Classificao de requisitos no-funcionais

Classificao de requisitos no-funcionais

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Impreciso dos requisitos

Impreciso dos requisitos

Em princpio, requisitos devem ser completos e consistentes

Na prtica, pode ser impossvel gerar um documento de requisitos completo e consistente

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Definio de objetivos e verificaes

E a Interface com o Usurio?

Requisito no-funcional verificvel

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Um requisito no-funcional verificvel

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Processo de engenharia de requisitos (ER)

Processo de Engenharia de Requisitos

Entretanto, existe um conjunto genrico de atividades comuns a todos os processos

Ricardo Choren 2011/IME

Ricardo Choren 2011/IME

Necessidades Informais Especificao da Soluo

Rejeitada Nova Especificao

Gerncia dos Requisitos