·
Análise de Sistemas ·
Informática
Send your question to AI and receive an answer instantly
Recommended for you
9
Introdução à Interdisciplinaridade e Requisitos na Educação
Informática
UNINASSAU
6
Orientações para Implementação de Soluções em Software
Informática
UNINASSAU
20
Documento de Arquitetura de Software - UNINASSAU EAD
Informática
UNINASSAU
11
Introdução à Disciplina: Estratégias de Aprendizagem Baseadas em Projetos
Informática
UNINASSAU
2
Analise de Dados e Relatorio de Margem de Contribuicao Planejada vs Realizada
Informática
UMESP
Preview text
1 Para início de conversa Olá Caroa estudante Preparado para nossa terceira unidade Então vamos dar continuidade a nossa viagem acadêmica buscando sempre novas interações e articulações com os conhecimentos já adquiridos Conto com sua total atenção em nossa jornada de estudos Lembrese seu comprometimento é a chave para seu sucesso profissional tudo depende de você orientações da disciPlina No último guia aprendemos a trabalhar com nossos clientes a fim de determinar o que eles querem que o sistema faça O resultado do processo de análise de requisitos consistiu em um documento que especifica as necessidades do cliente e explica o problema para os projetistas A etapa seguinte no desenvolvimento é traduzir esse desejo em uma solução um projeto que satisfaça às necessidades dos clientes Neste guia explicarei o que e como fazer para conseguir isso Alunoa geralmente nossos clientes querem um novo sistema porque ainda não existe algo disponível ou porque há aspectos indesejáveis no sistema antigo Em ambos os casos os documentos de requisitos nos informam sobre o problema que o sistema deve resolver O projeto é o processo criativo de transformar o problema em uma solução A descrição de uma solução também é chamada de projeto Para ver como os requisitos diferem do projeto considere o exemplo em que alguém pretende construir uma casa nova Os requisitos deles incluem itens como Um quarto para os três filhos brincarem e um local separado para eles dormirem Um quarto para os pais dormirem Uma cozinha Um sistema de aquecimento para o inverno e um de ar condicionado para o verão Água e eletricidade na casa Um arquiteto considera esses requisitos e projeta uma casa para a família O projeto arquitetural especifica uma solução particular por exemplo uma casa com quatro quartos no andar superior um quarto de visitas no térreo uma cozinha um quarto para as crianças brincarem e uma dispensa Na verdade o arquiteto pode produzir diversos projetos muito diferentes e cada um deles resolveria o problema Por exemplo um dos projetos poderia maximizar o espaço para as crianças brincarem e outro minimizar esse espaço de modo que a família tenha quartos grandes Além disso os estilos propostos para as casas podem ser diferentes o arquiteto pode mostrar para a família projetos para uma casa em estilo colonial com dois andares uma casa de campo e uma casa na cidade 2 você sabia Você sabia que diferentes projetos poderiam criar diferentes planos para resolver o mesmo problema e pode ser que não exista um projeto melhor Pois é a escolha da família depende de suas preferencias quanto às diferentes características de uma casa O projeto de software pode ser visto da mesma maneira Utilizamos a especificação dos requisitos para definir o problema Depois declaramos que determinada solução é adequada a um problema se ela satisfizer a todos os requisitos da especificação Em muitos casos o número de soluções possíveis é ilimitado Assim como a família pode escolher a casa que querem construir dentre suas muitas opções um cliente pode escolher implementar uma solução dentre diversas possibilidades Palavras do Professor Prezadoa estudante a natureza da solução pode se modificar à medida que a solução é descrita ou implementada Quando um arquiteto mostra um conjunto de projetos para a família eles podem decidir modificar as especificações como uma reação ao que eles gostam ou não gostam A decisão deles não é incomum nem irracional As modificações podem ter como base não um simples capricho mas uma nova percepção ou necessidade Por exemplo se a família decidirem ter um bebê poderão modificar as especificações da casa a fim de adicionar mais um quarto para a criança Se a família perceber que não foram bem compreendidos quanto a algum aspecto ou que se esqueceram de mencionar um requisito importante faz mais sentido para eles mudar as especificações do que aprender a viver em uma casa que não os agrada ou que de algum modo não se ajusta às suas necessidades Da mesma maneira a descrição de um sistema pode ser modificada durante o ciclo de desenvolvimento o que acontece com certa frequência Guarde essa ideia Para transformar os requisitos em um sistema funcional os projetistas devem satisfazer os clientes e os construtores de sistema da equipe de desenvolvimento Os clientes sabem o que o sistema deve fazer Ao mesmo tempo os construtores do sistema devem saber como o sistema funcionará Por essa razão o projeto é um processo iterativo composto de duas partes Primeiro criamos um projeto conceitual que mostra ao cliente exatamente o que o sistema fará Uma vez que o cliente aprova o projeto conceitual traduzimos esse projeto em um documento muito mais detalhado o projeto técnico que possibilita aos construtores do sistema saber quais são o hardware e software necessários para resolver o problema do cliente Assim o projeto conceitual se concentra nas funções do sistema e o projeto técnico descreve a forma que o sistema terá Esse conjunto de pontos de vista é semelhante às especificações da casa em que a família poderia examinar as plantas e esboços mas os construtores necessitam também de informações sobre a fiação o encanamento as lajes e colunas 3 Meu caroa a família não precisa se tornar perita em construção para saber exatamente qual será o resultado do trabalho De maneira semelhante os construtores não precisam conhecer tudo sobre a vida privada da família para entender o que eles querem ou necessitam Algumas vezes os clientes são muitos sofisticados e podem entender em conjunto o que e o como Isso pode acontecer quando os clientes são desenvolvedores de software e estamos construindo uma ferramenta para que utilizem no seu trabalho de desenvolvimento ou manutenção A figura a seguir ilustra o objetivo e os papéis envolvidos na criação de cada documento FONTE Pfleeger 2004 fica a dica É importante vincular o projeto técnico ao projeto conceitual de tal maneira que as mudanças ocorridas em um deles sejam refletidas no outro O projeto técnico descreve a configuração de hardware as necessidades de software as interfaces de comunicação a entrada e saída do sistema a arquitetura de rede e tudo o que traduz os requisitos em uma solução para o problema do cliente Isto é a descrição de projeto técnico é um retrato técnico da especificação do sistema Ela geralmente inclui os seguintes itens Uma descrição dos principais componentes de hardware e de suas funções A hierarquia e função dos componentes de software A estrutura e o fluxo de dados Projetar um sistema é determinar um conjunto de componentes e interfaces entre os componentes que satisfaça um conjunto especifico de requisitos Assim como existe várias maneiras de obter e documentar os requisitos também há vários modos de criar bons projetos Algumas vezes a escolha é feita com base nas preferências do projetista outras vezes o método é ditado pela estrutura ou pelos dados requeridos pelo sistema 4 ProJeto orientado a obJetos Palavras do Professor Vimos no guia anterior que os requisitos podem ser organizados por objetos e seus tipos abstratos O projeto pode também construir seus componentes em torno dos tipos abstratos de dados Ou seja cada componente é uma instância de um tipo de dados abstratos Portanto um projeto com base em um objeto deve ter duas importantes características o objeto deve preservar a integridade da representação dos dados e a representação dos dados deve ser ocultada dos outros objetos o encapsulamento A última característica facilita a modificação da implementação sem perturbar o restante do sistema Além disso a combinação de rotinas de acesso a objetos com os dados manipulados por eles incentiva os projetistas a decomporem o problema essencial em um conjunto de agentes que interagem entre si Contudo um objeto deve conhecer a identidade dos outros objetos para que possam interagir Caroa estudante existem duas diretrizes que se aplicam à representação de um projeto de sistema utilizando orientação a objetos Em primeiro lugar é importante identificar e representar as classes e os objetos Devemos conhecêlos não somente no mundo real domínio do problema mas também os detalhes dos atributos e comportamentos de cada um Em segundo lugar devemos identificar as interações e relações entre os objetos e as classes suas associações composições agregações e relações de herança O projeto do sistema é considerado uma abstração de alto nível do que eventualmente será o projeto do programa Começando com o projeto do sistema os projetistas de programa realizam várias etapas que fornecem os detalhes essenciais para a implementação Eles inserem aspectos computacionais nos modelos Eles inserem alguns detalhes da biblioteca de classes Eles inserem os requisitos nãofuncionais como o desempenho e a segurança e aprimoram o projeto de maneira adequada a estes requisitos rePresentando coM orientaçÃo a obJetos A UML Unified Modeling Language é uma abordagem de notação muito utilizada para descrever soluções orientadas a objetos Ela pode ser adaptada para se adequar a diferentes situações de desenvolvimento e ciclos de vida de software leitura coMPleMentar Clique aqui e veja os diagramas UML se preferir visite o material das disciplinas que trataram deste assunto 5 A UML pode ser utilizada para visualizar especificar ou documentar um problema Ela é especialmente útil para descrever diferentes projetos alternativos e eventualmente documentar os artefatos de projeto Os diagramas em UML incluem a visão dinâmica e estática do sistema além das restrições e da formalização A visão dinâmica é representada com os casos de uso listas de atividades diagramas de interação mostrando sequencia e colaboração e as máquinas de estado a fim de ilustrar os estados e suas mudanças Fonte httpsereduccom1j7LOs Já a visão estática é retratada pelos diagramas de classe que mostram as relações associações dependências e realizações e a extensibilidade restrições valores identificados por tags e estereótipos Além disso a visão estática mostra os pacotes e a implementação As restrições e a formalização são expressas com a OCL Object Constraint Language Fonte Pfleeger 2004 6 A figura acima mostra como a UML pode ser utilizada na especificação de requisitos no projeto e na codificação ferraMentas uMl Há na internet diversas ferramentas disponíveis para a geração de diagramas UML Existem desde soluções gratuitas e que contam com um bom suporte para a elaboração de representações baseadas nesta linguagem leitura coMPleMentar Como exemplo temos a ferramentas Astah que pode ser obtida clicando aqui A ferramenta Astah é disponível gratuitamente para estudantes Vários tutoriais sobre o uso e criação dos diagramas podem ser encontrados na internet Segue alguns links que oferecem material de apoio a criação destes diagramas Link 1 Link 2 fica a dica Chegou a hora de colocar a mão na massa Você como estudante de Análise e Desenvolvimento de Sistemas precisa saber projetar sistemas de informação Um entendimento aprimorado dos princípios da construção de sistemas de informação fará de você um profissional mais valioso Você será capaz de identificar pontos problemáticos e fazer sugestões durante o processo de projeto que irá resultar em um produto de melhor qualidade que satisfaça você seu cliente e o negócio Se precisar peço que interrompa neste momento a leitura deste guia de estudo e revise as vídeoaulas no seu Ambiente Virtual de Aprendizagem AVA das disciplinas relacionadas às competências e temas do componente de Formação específico da área de Tecnologia em Análise e Desenvolvimento de Sistemas Agora que você já revisou os assuntos relacionados à análise e projeto de sistemas dediquese a atividade prática desta unidade para que possamos avançar para o nosso próximo e ultimo tópico onde utilizaremos e iremos transformar os conhecimentos adquiridos até aqui em solução seguindo a proposta por você levantada atividade avaliativa Já passamos pela definição do problema e proposta de solução tecnológica já passamos também pela identificação e documentação dos requisitos do sistema Agora é hora de projetar esta solução e assim ficamos cada vez mais perto da implementação ou seja da hora de codificar nossa solução 7 Neste momento você deve selecionar um dos requisitos do sistema que foi levantado documentado e representado através dos seus casos de uso na unidade 2 Assim você deverá utilizar uma ferramenta de modelagem UML e construir os seguintes diagramas Diagrama de caso de uso Incluir na Atividade Avaliativa 2 Diagrama de classe Diagrama de instalação ou implantação UML 20 Foi disponibilizado o Documento de Arquitetura de Software nos materiais desta disciplina como Atividade Contextualizada É neste documento que você estudante deverá documentar o projeto de sua solução Para resuMir Para resumir neste guia mostramos a importância de projetar a solução antes de sua construção De forma que esta atividade não é realizada isoladamente os esforços de definição e especificação requerem que trabalhemos em conjunto com usuários clientes responsáveis pelos testes projetistas e outros membros da equipe A fim de permitir que a solução além de atender as necessidades do cliente possa ser mantida e evoluída facilmente Palavras do Professor Ufa Quanta informação não é Encerramos neste momento todo o conteúdo da Unidade III É importante que você tenha compreendido todo o assunto pois ele é a base para compreensão da unidade seguinte Na Unidade IV veremos com mais detalhes o conteúdo proposto e iremos abordar os elementos importantes acerca da avaliação prática pretendida Caso tenha alguma dúvida você deve entrar em contato com o tutor para que as esclareça Nos encontraremos na quarta e última unidade Até lá referências biblioGráficas Pfleeger Shari Lawrence Engenharia de Software teoria e prática 2ª edição Prentice Hall 2004
Send your question to AI and receive an answer instantly
Recommended for you
9
Introdução à Interdisciplinaridade e Requisitos na Educação
Informática
UNINASSAU
6
Orientações para Implementação de Soluções em Software
Informática
UNINASSAU
20
Documento de Arquitetura de Software - UNINASSAU EAD
Informática
UNINASSAU
11
Introdução à Disciplina: Estratégias de Aprendizagem Baseadas em Projetos
Informática
UNINASSAU
2
Analise de Dados e Relatorio de Margem de Contribuicao Planejada vs Realizada
Informática
UMESP
Preview text
1 Para início de conversa Olá Caroa estudante Preparado para nossa terceira unidade Então vamos dar continuidade a nossa viagem acadêmica buscando sempre novas interações e articulações com os conhecimentos já adquiridos Conto com sua total atenção em nossa jornada de estudos Lembrese seu comprometimento é a chave para seu sucesso profissional tudo depende de você orientações da disciPlina No último guia aprendemos a trabalhar com nossos clientes a fim de determinar o que eles querem que o sistema faça O resultado do processo de análise de requisitos consistiu em um documento que especifica as necessidades do cliente e explica o problema para os projetistas A etapa seguinte no desenvolvimento é traduzir esse desejo em uma solução um projeto que satisfaça às necessidades dos clientes Neste guia explicarei o que e como fazer para conseguir isso Alunoa geralmente nossos clientes querem um novo sistema porque ainda não existe algo disponível ou porque há aspectos indesejáveis no sistema antigo Em ambos os casos os documentos de requisitos nos informam sobre o problema que o sistema deve resolver O projeto é o processo criativo de transformar o problema em uma solução A descrição de uma solução também é chamada de projeto Para ver como os requisitos diferem do projeto considere o exemplo em que alguém pretende construir uma casa nova Os requisitos deles incluem itens como Um quarto para os três filhos brincarem e um local separado para eles dormirem Um quarto para os pais dormirem Uma cozinha Um sistema de aquecimento para o inverno e um de ar condicionado para o verão Água e eletricidade na casa Um arquiteto considera esses requisitos e projeta uma casa para a família O projeto arquitetural especifica uma solução particular por exemplo uma casa com quatro quartos no andar superior um quarto de visitas no térreo uma cozinha um quarto para as crianças brincarem e uma dispensa Na verdade o arquiteto pode produzir diversos projetos muito diferentes e cada um deles resolveria o problema Por exemplo um dos projetos poderia maximizar o espaço para as crianças brincarem e outro minimizar esse espaço de modo que a família tenha quartos grandes Além disso os estilos propostos para as casas podem ser diferentes o arquiteto pode mostrar para a família projetos para uma casa em estilo colonial com dois andares uma casa de campo e uma casa na cidade 2 você sabia Você sabia que diferentes projetos poderiam criar diferentes planos para resolver o mesmo problema e pode ser que não exista um projeto melhor Pois é a escolha da família depende de suas preferencias quanto às diferentes características de uma casa O projeto de software pode ser visto da mesma maneira Utilizamos a especificação dos requisitos para definir o problema Depois declaramos que determinada solução é adequada a um problema se ela satisfizer a todos os requisitos da especificação Em muitos casos o número de soluções possíveis é ilimitado Assim como a família pode escolher a casa que querem construir dentre suas muitas opções um cliente pode escolher implementar uma solução dentre diversas possibilidades Palavras do Professor Prezadoa estudante a natureza da solução pode se modificar à medida que a solução é descrita ou implementada Quando um arquiteto mostra um conjunto de projetos para a família eles podem decidir modificar as especificações como uma reação ao que eles gostam ou não gostam A decisão deles não é incomum nem irracional As modificações podem ter como base não um simples capricho mas uma nova percepção ou necessidade Por exemplo se a família decidirem ter um bebê poderão modificar as especificações da casa a fim de adicionar mais um quarto para a criança Se a família perceber que não foram bem compreendidos quanto a algum aspecto ou que se esqueceram de mencionar um requisito importante faz mais sentido para eles mudar as especificações do que aprender a viver em uma casa que não os agrada ou que de algum modo não se ajusta às suas necessidades Da mesma maneira a descrição de um sistema pode ser modificada durante o ciclo de desenvolvimento o que acontece com certa frequência Guarde essa ideia Para transformar os requisitos em um sistema funcional os projetistas devem satisfazer os clientes e os construtores de sistema da equipe de desenvolvimento Os clientes sabem o que o sistema deve fazer Ao mesmo tempo os construtores do sistema devem saber como o sistema funcionará Por essa razão o projeto é um processo iterativo composto de duas partes Primeiro criamos um projeto conceitual que mostra ao cliente exatamente o que o sistema fará Uma vez que o cliente aprova o projeto conceitual traduzimos esse projeto em um documento muito mais detalhado o projeto técnico que possibilita aos construtores do sistema saber quais são o hardware e software necessários para resolver o problema do cliente Assim o projeto conceitual se concentra nas funções do sistema e o projeto técnico descreve a forma que o sistema terá Esse conjunto de pontos de vista é semelhante às especificações da casa em que a família poderia examinar as plantas e esboços mas os construtores necessitam também de informações sobre a fiação o encanamento as lajes e colunas 3 Meu caroa a família não precisa se tornar perita em construção para saber exatamente qual será o resultado do trabalho De maneira semelhante os construtores não precisam conhecer tudo sobre a vida privada da família para entender o que eles querem ou necessitam Algumas vezes os clientes são muitos sofisticados e podem entender em conjunto o que e o como Isso pode acontecer quando os clientes são desenvolvedores de software e estamos construindo uma ferramenta para que utilizem no seu trabalho de desenvolvimento ou manutenção A figura a seguir ilustra o objetivo e os papéis envolvidos na criação de cada documento FONTE Pfleeger 2004 fica a dica É importante vincular o projeto técnico ao projeto conceitual de tal maneira que as mudanças ocorridas em um deles sejam refletidas no outro O projeto técnico descreve a configuração de hardware as necessidades de software as interfaces de comunicação a entrada e saída do sistema a arquitetura de rede e tudo o que traduz os requisitos em uma solução para o problema do cliente Isto é a descrição de projeto técnico é um retrato técnico da especificação do sistema Ela geralmente inclui os seguintes itens Uma descrição dos principais componentes de hardware e de suas funções A hierarquia e função dos componentes de software A estrutura e o fluxo de dados Projetar um sistema é determinar um conjunto de componentes e interfaces entre os componentes que satisfaça um conjunto especifico de requisitos Assim como existe várias maneiras de obter e documentar os requisitos também há vários modos de criar bons projetos Algumas vezes a escolha é feita com base nas preferências do projetista outras vezes o método é ditado pela estrutura ou pelos dados requeridos pelo sistema 4 ProJeto orientado a obJetos Palavras do Professor Vimos no guia anterior que os requisitos podem ser organizados por objetos e seus tipos abstratos O projeto pode também construir seus componentes em torno dos tipos abstratos de dados Ou seja cada componente é uma instância de um tipo de dados abstratos Portanto um projeto com base em um objeto deve ter duas importantes características o objeto deve preservar a integridade da representação dos dados e a representação dos dados deve ser ocultada dos outros objetos o encapsulamento A última característica facilita a modificação da implementação sem perturbar o restante do sistema Além disso a combinação de rotinas de acesso a objetos com os dados manipulados por eles incentiva os projetistas a decomporem o problema essencial em um conjunto de agentes que interagem entre si Contudo um objeto deve conhecer a identidade dos outros objetos para que possam interagir Caroa estudante existem duas diretrizes que se aplicam à representação de um projeto de sistema utilizando orientação a objetos Em primeiro lugar é importante identificar e representar as classes e os objetos Devemos conhecêlos não somente no mundo real domínio do problema mas também os detalhes dos atributos e comportamentos de cada um Em segundo lugar devemos identificar as interações e relações entre os objetos e as classes suas associações composições agregações e relações de herança O projeto do sistema é considerado uma abstração de alto nível do que eventualmente será o projeto do programa Começando com o projeto do sistema os projetistas de programa realizam várias etapas que fornecem os detalhes essenciais para a implementação Eles inserem aspectos computacionais nos modelos Eles inserem alguns detalhes da biblioteca de classes Eles inserem os requisitos nãofuncionais como o desempenho e a segurança e aprimoram o projeto de maneira adequada a estes requisitos rePresentando coM orientaçÃo a obJetos A UML Unified Modeling Language é uma abordagem de notação muito utilizada para descrever soluções orientadas a objetos Ela pode ser adaptada para se adequar a diferentes situações de desenvolvimento e ciclos de vida de software leitura coMPleMentar Clique aqui e veja os diagramas UML se preferir visite o material das disciplinas que trataram deste assunto 5 A UML pode ser utilizada para visualizar especificar ou documentar um problema Ela é especialmente útil para descrever diferentes projetos alternativos e eventualmente documentar os artefatos de projeto Os diagramas em UML incluem a visão dinâmica e estática do sistema além das restrições e da formalização A visão dinâmica é representada com os casos de uso listas de atividades diagramas de interação mostrando sequencia e colaboração e as máquinas de estado a fim de ilustrar os estados e suas mudanças Fonte httpsereduccom1j7LOs Já a visão estática é retratada pelos diagramas de classe que mostram as relações associações dependências e realizações e a extensibilidade restrições valores identificados por tags e estereótipos Além disso a visão estática mostra os pacotes e a implementação As restrições e a formalização são expressas com a OCL Object Constraint Language Fonte Pfleeger 2004 6 A figura acima mostra como a UML pode ser utilizada na especificação de requisitos no projeto e na codificação ferraMentas uMl Há na internet diversas ferramentas disponíveis para a geração de diagramas UML Existem desde soluções gratuitas e que contam com um bom suporte para a elaboração de representações baseadas nesta linguagem leitura coMPleMentar Como exemplo temos a ferramentas Astah que pode ser obtida clicando aqui A ferramenta Astah é disponível gratuitamente para estudantes Vários tutoriais sobre o uso e criação dos diagramas podem ser encontrados na internet Segue alguns links que oferecem material de apoio a criação destes diagramas Link 1 Link 2 fica a dica Chegou a hora de colocar a mão na massa Você como estudante de Análise e Desenvolvimento de Sistemas precisa saber projetar sistemas de informação Um entendimento aprimorado dos princípios da construção de sistemas de informação fará de você um profissional mais valioso Você será capaz de identificar pontos problemáticos e fazer sugestões durante o processo de projeto que irá resultar em um produto de melhor qualidade que satisfaça você seu cliente e o negócio Se precisar peço que interrompa neste momento a leitura deste guia de estudo e revise as vídeoaulas no seu Ambiente Virtual de Aprendizagem AVA das disciplinas relacionadas às competências e temas do componente de Formação específico da área de Tecnologia em Análise e Desenvolvimento de Sistemas Agora que você já revisou os assuntos relacionados à análise e projeto de sistemas dediquese a atividade prática desta unidade para que possamos avançar para o nosso próximo e ultimo tópico onde utilizaremos e iremos transformar os conhecimentos adquiridos até aqui em solução seguindo a proposta por você levantada atividade avaliativa Já passamos pela definição do problema e proposta de solução tecnológica já passamos também pela identificação e documentação dos requisitos do sistema Agora é hora de projetar esta solução e assim ficamos cada vez mais perto da implementação ou seja da hora de codificar nossa solução 7 Neste momento você deve selecionar um dos requisitos do sistema que foi levantado documentado e representado através dos seus casos de uso na unidade 2 Assim você deverá utilizar uma ferramenta de modelagem UML e construir os seguintes diagramas Diagrama de caso de uso Incluir na Atividade Avaliativa 2 Diagrama de classe Diagrama de instalação ou implantação UML 20 Foi disponibilizado o Documento de Arquitetura de Software nos materiais desta disciplina como Atividade Contextualizada É neste documento que você estudante deverá documentar o projeto de sua solução Para resuMir Para resumir neste guia mostramos a importância de projetar a solução antes de sua construção De forma que esta atividade não é realizada isoladamente os esforços de definição e especificação requerem que trabalhemos em conjunto com usuários clientes responsáveis pelos testes projetistas e outros membros da equipe A fim de permitir que a solução além de atender as necessidades do cliente possa ser mantida e evoluída facilmente Palavras do Professor Ufa Quanta informação não é Encerramos neste momento todo o conteúdo da Unidade III É importante que você tenha compreendido todo o assunto pois ele é a base para compreensão da unidade seguinte Na Unidade IV veremos com mais detalhes o conteúdo proposto e iremos abordar os elementos importantes acerca da avaliação prática pretendida Caso tenha alguma dúvida você deve entrar em contato com o tutor para que as esclareça Nos encontraremos na quarta e última unidade Até lá referências biblioGráficas Pfleeger Shari Lawrence Engenharia de Software teoria e prática 2ª edição Prentice Hall 2004