Engenharia de Sistemas e Software

Transcrição

1 Resumo Este é um material de estudo (notas de aula) da disciplina de engenharia de sistemas e software do curso de pós-graduação Lato Sensu em da UEG, Câmpus Itaberaí. Tem como objetivo garantir aos estudantes uma leitura auxiliar dos referenciais teóricos da disciplina e não deve substituí-los. Consta de um apanhado de autores das disciplinas de engenharia de software, análise de sistemas e gestão de sistemas de informação. O foco da disciplina é gestão, portanto, passa pelos aspectos iniciais da engenharia de software, buscando abranger, além de técnicas, distintos papeis envolvidos nos processos de concepção de sistemas de computação, com foco especial em projetos relacionados a software. Introdução Do ponto de vista da gestão da tecnologia da informação, a engenharia de sistemas e software é uma importante área que demanda habilidades e conhecimentos de técnicas e ferramentas específicas para construção e manutenção de sistemas de informação (softwares em grande parte) que certamente farão parte da vida profissional dos gestores. A boa prática muitas vezes é fundamental para o sucesso, mas nem sempre é garantia dele. A experiência, criatividade, capacidade de adaptação a diferentes realidades, e até mesmo um pouco de sorte (sobretudo com pessoas) podem fazer a diferença em projetos bem sucedidos. Além do mais, estamos lidando com informação, e como bem sabemos, ela é totalmente suscetível a falhas e diferentes interpretações. Estamos também lidando com tecnologia, e esta por sua vez, é completamente suscetível ao tempo. Não há nada que resista ao chamado da evolução tecnológica e da informação. Assim foram os primeiros veículos da imprensa arcaica, passando por muitas revoluções, e chegando à era da geração de

2 computadores que conhecemos desde o século passado e suas inovações dos dias atuais. E, não menos importante, na era da informação massiva em inúmeras facetas que permitem, além do consumo, diferentes formas de análise para tomadas de decisão. A engenharia de sistemas e software deve ir além de tecnologias específicas, em especial, no que diz respeito ao manuseio, armazenamento, e recuperação das informações, pois como é possível analisar até aqui, tanto a tecnologia como a informação são volúveis ao tempo e às experimentações sociais. Ainda assim, essa mesma engenharia deve estar alinhada com o tempo e com o espaço em que se coexiste a tríplice: sociedade, tecnologia e informação; já que é do jogo de interações entre essas três grandezas que se obtém os caminhos para criação de soluções viáveis que levam o ser humano à construção do conhecimento.

3 Aula 1: Tópicos abordados: Sistema, sistema de informação e software; Engenharia de sistemas e engenharia de software; I Princípios de Engenharia de Sistemas e Software 1. Introdução à engenharia de Software Segundo (Sommerville, 2011) o mundo não poderia existir sem software. O mundo imaginado em um recorte que vai além do modelo físico, claro. Ao se avaliar os países, as organizações, as pessoas vivendo em sociedade, é praticamente impossível encontrar algum setor da sociedade que não seja controlado, por menor que seja o controle, por softwares. Os sistemas de software são abstratos e intangíveis. Eles não são restringidos pelas propriedades dos materiais, nem governados pelas leis da física ou pelos processos de manufatura. (Sommerville, 2011) Esses pressupostos iniciais da natureza dos softwares obrigam os profissionais responsáveis pelos diversos processos das fases de sua existência a lançarem mão de estratégias que vão além daquelas conhecidas em outros ramos da engenharia. No entanto essa diferença fundamental não exclui a necessidade de criar softwares que respeitem critérios de qualidade, custo e prazo. Não temos todo o tempo do mundo, não temos todo o dinheiro disponível e precisamos que os softwares atendam nossas necessidades com garantias que irão funcionar quando forem exigidos. Fundamentos da engenharia de software (Sommerville, 2011) 1. Softwares devem ser desenvolvidos em um processo gerenciado e compreendido. A organização que desenvolve o software deve planejar o processo de desenvolvimento e ter ideias claras do que será produzido e quando estará finalizado, Respeitando que processos diferentes são usados para tipos diferentes de software. 2. Confiança e desempenho são importantes para todos os tipos de sistema. O software deve se comportar conforme o esperado, sem falhas, e deve estar disponível para o uso quando requerido. Deve ser seguro em suas operações e protegido contra ataques externos. O sistema deve funcionar de forma equilibrada e eficiente e não deve desperdiçar recursos. 3. É importante entender e gerenciar as especificações e os requisitos de software ( o que fazer). Você deve saber o que os clientes e usuários esperam dele e deve gerenciar suas expectativas para que um sistema útil possa ser entregue dentro do orçamento e do cronograma. 4. Você deve fazer o melhor uso possível dos recursos existentes. Isso significa que, quando apropriado, você deve reusar o software já desenvolvido, em vez de escrever um novo. A Engenharia de Software é importante por dois motivos: 1) cada vez mais indivíduos e sociedades dependem dos sistemas e softwares avançados. Temos ser capazes de produzi-los confiáveis de forma econômica e rápida. 2) Geralmente é mais barato, a longo prazo, usar métodos e técnicas da engenharia de software para sistemas de software para sistemas de

4 software, em vez de simplesmente escrever programas como se fossem projetos pessoais. Para a maioria dos sistemas, a maior parte do custo é mudar o software depois que ele começa a ser usado Sistemas versus Software Muitas vezes confundimos o termo sistema com software. Isto é comum, e até certo ponto aceitável, uma vez que o costume social com a tecnologia da informação fez que com que esse termo fosse apossado, e por algumas vezes entendido como sinônimo um do outro dentro e fora do mundo da computação. (Rosini, 2014) afirma a palavra muitas vezes é usada de forma indiscriminada e sem qualquer critério. Um sistema pode ser entendido como um mecanismo composto por um conjunto de parte inter-relacionadas, onde cada parte está sempre relacionada a, pelo menos, uma das outras (Pompilho, 2002). Isto é, há interdependência entre as partes do sistema. Estes componentes, vistos de forma separada, podem ser entendidos como subsistemas de um sistema maior, trazendo, portanto, a ideia que os sistemas apresentam uma hierarquia que pode ser interna ou externa, dependendo de como se visualiza um sistema em relação às suas partes. A Teoria geral dos sistemas é quem abrange os aspectos teóricos relacionados aos sistemas de uma maneira geral, tendo sido desenvolvida por Ludwig Von Bertalanffy, no século passado. (Pesquise mais informações sobre a teoria geral dos sistemas na internet). Em uma visão geral, os softwares são produtos desenvolvidos por profissionais que o desenvolvem e dão suporte a longo prazo. Abrange programas executáveis e outros artefatos (arquitetura, conteúdos, documentos, etc) que fazem parte das fases de sua existência, desde sua concepção até sua manutenção (Pressman, 2011). E qual a diferença entre engenharia de software e engenharia de sistemas? A engenharia de sistemas diz respeito a todos os aspectos do desenvolvimento e da evolução de sistemas complexos, nos quais, o software desempenha um papel importante. A engenharia de sistemas envolve o desenvolvimento de hardware, projeto de políticas e de processos e implantação do sistema, assim como com a engenharia de software. Os engenheiros de sistema estão envolvidos com a especificação de sistema, com a definição de sua arquitetura geral, e, em seguida, com a integração de diferentes partes necessárias para criar o sistema final A natureza do software (Pressman, 2011): Hoje, o software assume um duplo papel. Ele é produto e, ao mesmo tempo, veículo para distribuir um produto. Como produto fornece potencial computacional representado pelo hardware, ou de forma mais abrangente, por uma dede de computadores que podem ser acessados por hardware local. Independente de estar num celular ou num mainframe, o software age como um transformador de informação, produzindo, gerenciando, adquirindo, exibindo, ou transmitindo informações que podem ser tão simples quanto um único bit, ou complexas, como uma apresentação de multimídia. Como veículo de distribuição, o software

5 pode atuar como a base para o controle do computador (sistemas operacionais). Comunicação de informações (redes), criação e controle de outros programas (ferramentas de software e ambiente). O software distribui o produto mais importante de nossa era: a informação. Transforma dados de forma a ser mais útil em um determinado contexto. Gerencia informações comerciais; fornece um portal para redes mundiais de informação (internet) e os meios para obter informações sob todas as suas formas. O papel desempenhado pelo software tem passado por grandes modificações nos últimos 50 anos. Aperfeiçoamentos significativos de hardware, mudanças profundas de arquiteturas computacionais, aumento de capacidade de memória e armazenamento e uma grade variedade de dispositivos de entrada e saída resultou em sistemas computacionais mais sofisticados e complexos. Todos esses fatores podem trazer resultados impressionantes quando o software é bem sucedido, porém podem trazer diversos problemas para quem precisa desenvolver sistemas robustos. Atualmente, uma enorme indústria de software tornou-se fator nas economias do mundo industrializado. Equipes de especialistas em software substituíram a figura do programador solitário de antigamente. Ainda assim, as questões levantadas por esse programador solitário continuam as mesmas até hoje: Por que concluir um software leva tanto tempo? Por que os custos de desenvolvimento são tão altos? Por que não conseguimos encontrar todos os erros antes da entrega do software aos clientes? Por que gastamos tanto tempo e esforço mantendo programas existentes? Por que continuamos a ter dificuldade em medir o progresso enquanto o software está sendo desenvolvido e mantido? Diferentemente do hardware, o software apresenta algumas características peculiares que devem ser levadas em consideração: 1. Software não é fabricado (no sentido geral da palavra). 2. Software não se desgasta 3. Embora a indústria caminhe para a construção com base em componentes, a maioria dos softwares continua a ser construída de forma personalizada. 2. Sistemas Sociotécnicos Sistemas sociotécnicos envolvem hardware, software, pessoas e processos. Suas características essenciais são: 1. Eles possuem propriedades emergentes, que são propriedades do sistema como um todo. (interdependência) 2. São sistemas não determinísticos. 3. A entidade que usa o sistema não depende apenas do sistema em si.

6 Exercícios 1. Como o uso universal da internet mudou os sistemas de software? Como isso te afeta como profissional de TI? 2. De maneira geral, quais atributos um software deve possuir para ser um bom produto nos dias atuais? 3. Quais as diferenças entre desenvolver um produto genérico e software sob demanda? O que isso implica em relação a custos? 4. Pense em cenários envolvendo sistemas com três níveis de complexidade (Pequena, média e alta). Extraia quais aspectos são relevantes para a construção e manutenção de cada um desses sistemas. Pense em termos de recursos humanos e materiais, o que é preciso pra esses sistemas funcionarem? Pense em termos de evolução tecnológica, quanto tempo esse sistema pode viver e quais estratégias pra que ele não morra. Pense em termos de tempo e custo para cada um (sem entrar em detalhes demasiado técnicos)

7 Aula 2 Tópicos abordados: Ciclo de vida, modelagem de sistemas, engenharia de requisitos; I - Processos de Software Um processo de software é um conjunto de atividades relacionadas que levam à produção de um produto de software. Podem estar relacionadas à concepção de um software do zero, ou extensão e modificação de sistemas já existentes. (Businness Intelligence, por exemplo) Todo processo de software deve possuir uma metodologia, isto é, um conjunto de regras, diretrizes e estratégias a serem seguidas para que o trabalho seja desenvolvido. (Não se engane. Mesmo aqueles que dizem não seguir uma metodologia estão seguindo, mesmo que intuitivamente). As atividades fundamentais para a engenharia de software são: (Sommerville, 2011) 1. Especificação do software 2. Projeto e implementação 3. Validação 4. evolução 1. Modelos de processos de software Modelos de processo de software são representações simplificadas de um processo de software. Cada modelo representa uma perspectiva particular do processo (fornecendo informações parciais sobre ele). Um modelo de atividades foca nas atividades e sua sequência, mas pode não ser relevante mostrar papeis. Dessa forma, os modelos devem ser usados sempre para visualizar o software ou parte dele sobre determinadas perspectivas. Os modelos mais vistos na engenharia de software são o modelo em cascata, desenvolvimento incremental, e engenharia de software orientada a reuso (Sommerville, 2011). 1.1 Modelo em cascata

8 No modelo em cascata, em princípio, você deve planejar e programar todas as atividades do processo antes de começar a trabalhar nelas. Os principais estágios do modelo em cascata refletem diretamente as atividades fundamentais do desenvolvimento. 1. Análise e definição dos requisitos: Os serviços, ou restrições e metas do sistema são estabelecidos por meio de consultas a usuários. Em seguida são definidos em detalhes e funcionam como uma especificação do sistema. 2. Projeto de sistema e software: O processo de projeto de sistemas aloca os requisitos tanto para sistemas de hardware como para sistemas de software, por meio de uma arquitetura geral para o sistema. O projeto de software envolve identificação e descrição das abstrações fundamentais do sistema de software e seus relacionamentos. 3. Implementação e teste unitário: durante esse estágio, o projeto de software é desenvolvido como um conjunto de programas ou unidades de programa. O teste unitário envolve a verificação de que cada unidade atenda sua especificação. 4. Integração e teste de sistema: As unidades individuais do programa ou programas são integradas e testadas como um sistema completo para assegurar que os requisitos do software tenham sido atendidos. Após o teste, o sistema de software é entregue ao cliente. 5. Operação e manutenção: normalmente (embora não necessariamente) essa é a fase mais longa do ciclo de vida. O sistema é instalado e colocado em uso. A manutenção envolve correção de erros que não foram descobertos em estágios iniciais do ciclo de vida, com melhora da implementação das unidades do sistema e ampliação de seus serviços e em resposta às descobertas de novos requisitos. Como boa prática, o resultado de cada estágio é a aprovação de um ou mais documentos assinados. O estágio seguinte não pode ser iniciado até que a fase anterior seja concluída. Na prática, esses estágios se sobrepõem e alimentam uns aos outros de informações. Durante o projeto, os problemas com os requisitos são identificados. Durante a codificação os problemas de projeto são encontrados e assim por diante.

9 O processo de software não é um modelo linear simples. Envolve feedback de uma fase pra outra. Assim documentos produzidos em cada fase podem ser modificados para refletirem as alterações feitas em cada um deles. Por causa dos custos de produção e aprovação dos documentos, as iterações podem ser dispendiosas e envolver significativo retrabalho. Assim, após um pequeno número de iterações, é normal congelarem as partes do desenvolvimento, como a especificação, e dar-se continuidade aos estágios posteriores de desenvolvimento. A solução do problema fica pra mais tarde, ignorada ou programada, quando possível. Esse congelamento prematuro dos requisitos pode resultar em um sistema que não atenda em partes o que o usuário quer. Também pode levar a sistemas mal estruturados, quando os problemas de projeto são contornados por artifícios de implementação. Durante o estágio final do ciclo de vida, o software é colocado em uso. Erros e omissões nos requisitos originais do software são descobertos. Os erros de programa e projeto aparecem e são identificadas novas necessidades funcionais. O sistema deve evoluir para permanecer útil. Fazer essas alterações (manutenção do software) pode implicar em repetições de estágios anteriores do processo. O modelo em cascata é consistente com outros modelos de processo de engenharia e a documentação é produzida em cada fase do ciclo. Dessa forma, o processo torna-se visível, e os gestores podem monitorar o progresso de acordo com o plano de desenvolvimento. Seu maior problema é a divisão inflexível do projeto em estágios distintos. Os compromissos devem ser assumidos em um estágio inicial do processo, o que dificulta que antedá as mudanças de requisitos dos clientes. Em princípio, o modelo em cascata deve ser usado apenas quando os requisitos são bem compreendidos e pouco provavelmente alterados durante o desenvolvimento do sistema. No entanto, o modelo em cascata reflete o tipo de processo usado em outros projetos de engenharia. Como é mais fácil usar um modelo de gerenciamento comum para todo o projeto, projetos de software baseados no modelo em cascata ainda não comumente utilizados Desenvolvimento incremental O desenvolvimento incremental é baseado na ideia de desenvolver uma implementação inicial, expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido. Atividades de especificação, desenvolvimento e validação são intercaladas, e não separadas, como rápido feedback entre todas as atividades.

10 O desenvolvimento incremental é base fundamental para as atividades de desenvolvimento ágeis. É melhor do que o modelo em cascata para a maioria dos sistemas de negócio e-commerce e sistemas pessoais. Desenvolvimento incremental reflete a maneira como resolvemos os problemas. Raramente elaboramos uma solução completa para um problema de forma antecipada. Normalmente movemos para a solução passo a passo, recuando quando percebemos que cometemos um erro. Ao se apoiar no modelo incremental, torna-se mais barato e mais fácil fazer mudanças no software durante o desenvolvimento. Cada incremento ou função do sistema incorpora uma funcionalidade necessária para o cliente. Frequentemente os incrementos iniciais incluem as funcionalidades mais importantes ou mais urgentes (ou aquelas que são base para as demais). Isso significa que o cliente pode avaliar o sistema em um estágio relativamente inicial do desenvolvimento para ver se ele oferece o que foi requisitado. Em caso negativo, só o incremento que estiver em desenvolvimento no momento precisará ser alterado e, possivelmente, nova funcionalidade deverá ser definida para incrementos posteriores. O desenvolvimento incremental apresenta três vantagens em relação ao modelo em cascata. 1. Custo de acomodar as mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação a ser refeita é muito menor. 2. É mais fácil obter feedbacks dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software. 3. É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se toda funcionalidade não for incluída. Assim os clientes podem ter ganhos com o software mesmo antes do que é possível com um modelo em cascata.

11 Esta atualmente a abordagem mais comum. Pode ser dirigida a planos, ágil, ou mais comum, uma combinação entre elas. Em abordagens a planos, os incrementos são identificados previamente. Se uma abordagem ágil for adotada, os incrementos iniciais são identificados, mas o desenvolvimento de incrementos posteriores depende do progresso e das prioridades dos clientes. Do ponto de vista do gerenciamento, a abordagem incremental tem dois problemas: 1. O processo não é visível (totalmente). Os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas são desenvolvidos com rapidez, não é economicamente viável produzir documentos que reflitam cada uma das versões do sistema. 2. A estrutura do sistema tende a se degradar com a adição de novos incrementos. A menos que tempo e dinheiro sejam dispendidos em refatoração para melhoria do software, as constantes mudanças tendem a corromper sua estrutura. Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso. O problemas do desenvolvimento incremental são especialmente críticos para os sistemas de vida longa, grandes e complexos, no qual várias equipes desenvolvem partes diferentes do sistema. Sistemas de grande porte necessitam de um framework ou arquitetura estável, e as responsabilidades das diferentes equipes de trabalho do sistema precisam ser claramente definidas, respeitando essa arquitetura. Isso deve ser planejado com antecedência, e não ser desenvolvido de forma incremental. Você pode desenvolver um sistema de forma incremental e expô-lo aos comentários dos clientes, sem realmente entrega-lo e implantá-lo no ambiente operacional do cliente. Entrega e implantação incremental significa que o software é usado em processos operacionais reais. Isso nem sempre é possível, pois experimentações com o novo software podem interromper os processos normais do negócio Engenharia de software orientada a reuso. Na maioria dos projetos de software, há algum reuso de software. Isso acontece muitas vezes informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou códigos semelhantes. Elas buscam, fazem adequações necessárias e incorporam a seu projeto. Esse reuso informal ocorre independente do processo de desenvolvimento que se use. No entanto, nos últimos anos os processos com foco no reuso tornaram-se amplamente usados. Abordagens orientadas no reuso dependem de uma boa base de componentes reusáveis e de um framework de integração para a composição desses componentes, que podem ser sistemas completos, capazes de fornecer uma funcionalidade específica, como um processamento de texto ou planilha. Embora as etapas iniciais do processo possa ser semelhante com as demais, a parte intermediária apresenta diferenças fundamentais. Esses estágios são:

12 1. Análise de componentes. A partir das especificações dos requisitos, é feita uma busca por componente para implementar essa especificação. Em geral, não há correspondência exata, e os componentes que podem ser usados fornecem apenas algumas funcionalidades necessárias. 2. Modificação de requisitos: durante esse estágio, os requisitos são analisados usando-se informações sobre os componentes disponíveis. No caso de modificações impossíveis, a atividade de análise dos componentes pode ser reinserida na busca por soluções alternativas. 3. Projeto do Sistema com reuso: durante esse estágio, o framework do sistema é projetado ou algo existente é reusado. Os projetistas tem em mente os componentes que serão reusados e organizam o framework para reuso. Alguns softwares novos serão necessários se componentes reusáveis não estiverem disponíveis. 4. Desenvolvimento e integração: software que não podem ser adquiridos externamente são desenvolvidos, e os componentes e sistemas completos são integrados para criar um novo sistema. A integração de sistema, neste modelo, pode ser parte do processo de desenvolvimento, em vez de uma atividade separada. Existem três tipos de componentes de software que podem ser usados em um processo de reuso: 1. Web services desenvolvidos de acordo com padrões de serviço e que estão disponíveis para invocação remota. 2. Coleções de objetos que são desenvolvidas como um pacote a ser integrado com um framework de componentes como o J2EE e o.net. 3. Sistemas de software stand-alone configurados para um em um ambiente particular. Este modelo de processo apresenta vantagens óbvias em relação aos vistos até o momento. Pode ser mais rápido, mais barato e possuir menos riscos. No entanto, não se pode abandonar o compromisso com os requisitos. Isso pode levar a um software que não atende as reais necessidade do usuário. Além disso, algum controle sobre a evolução do sistema é perdido, pois as novas versões dos componentes reusáveis não estão sob o controle da organização que o está utilizando.

13 2. Atividades do processo. Processos reais de software são intercalados com sequências de atividades técnicas, de colaboração e de gerência, com o intuito de especificar, projetar, implementar e testar um sistema de software. Os desenvolvedores de software usam uma variedade de diferentes ferramentas para seu trabalho. Elas são úteis para apoiar a edição de diferentes tipos de documentos e para gerenciar o imenso volume de informação que gerado em um projeto (em especial de grande porte). As quatro atividades básicas do projeto são organizadas de forma diferente conforme o processo de desenvolvimento. 2.1 Especificação de software (ou engenharia de requisitos) É o processo de compreensão e definição dos serviços requisitados do sistema e identificação de restrições relativas à operação e ao desenvolvimento do sistema. A engenharia de requisitos é um estágio particularmente crítico do processo de software, pois erros nessa fase inevitavelmente geram problemas no projeto e na implementação do sistema. O processo de engenharia de requisitos tem como objetivo produzir um documento de requisitos acordados que especifica um sistema que satisfaz os requisitos dos clientes. Requisitos são geralmente apresentados em dois níveis de detalhe. Os usuários finais e os clientes precisam de uma declaração de requisitos em alto nível; desenvolvedores de sistemas precisam de uma especificação mais detalhada. Existem quatro atividades do processo de engenharia de requisitos: 1. Estudo de viabilidade 2. Elicitação e análise de requisitos 3. Especificação de requisitos 4. A validação dos requisitos 2.2. Projeto e implementação de software

14 O estágio de implementação do desenvolvimento do software é o processo de conversão de uma especificação em um sistema executável. Sempre envolve processos de projeto e programação de software. Mas se for usada uma abordagem incremental para o desenvolvimento, também pode envolver o refinamento da especificação do software. O projeto de software é uma descrição da estrutura do software a ser implementado, dos modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema, e às vezes, dos algoritmos usados. Os projetistas não chegam a um projeto final imediatamente, mas desenvolvem-no de forma iterativa. Eles acrescentam formalidade e detalhe, enquanto desenvolvem seu projeto por meio de revisões constantes para correção de projetos anteriores. As atividades no processo de projeto podem variar, dependendo do tipo de sistema ser desenvolvido. 1. Projeto de arquitetura: identificar a estrutura geral do sistema, componentes principais, subsistemas, módulos, seus relacionamentos e como eles são distribuídos. 2. Projeto de interface: define as interfaces entre os componentes do sistema. Essa especificação de interface deve ser inequívoca. Com uma interface precisa, um componente pode ser usado de maneira que outros componentes não precisam saber como ele é implementado. Uma vez que a especificação de interfaces é acordada, os componentes podem ser projetos e desenvolvidos simultaneamente. 3. Projeto de componente. Projeta como é o funcionamento de cada componente do sistema. Pode ser uma simples declaração de funcionalidade que se deseja implementar com um projeto específico para cada programador. O modelo de projeto pode ser usado para gerar automaticamente uma implementação. 4. Projeto de banco de dados: como os dados do sistema devem ser representados no banco de dados. Atenção para o mapeamento objeto-relacional Validação de Software

15 Tem a intenção de mostrar que se um software se adequa a especificação de seus requisitos. A principal técnica de validação é execução do sistema com dados simulados. A validação também envolve processo de verificação com inspeções e revisões de cada etapa do processo. A maior parte dos custos de testes está após a implementação. Com exceção de pequenos programas, os sistemas não devem ser testados como uma unidade única e monolítica. Quando defeitos são descobertos, o programa deve ser depurado e isso pode requerer que outros estágios do processo de testes sejam repetidos. O processo de testes é iterativo com informações realimentadas de estágios posteriores para partes anteriores do processo. 1. Testes de desenvolvimento Componentes são testados pelos desenvolvedores. Cada componente é testado de forma independente Componentes podem ser entidades simples ou agrupamento destas. Podem ser utilizadas ferramentas de testes automatizados (JUnit). 2. Testes de sistema Componentes do sistema são integrados para criar um sistema completo. Se preocupa em encontrar erros resultantes das iterações inesperadas entre componentes e problemas de interface do componente. Visa mostrar também que o sistema satisfaz seus requisitos funcionais e não funcionais Testa propriedades emergentes do sistema 3. Testes de aceitação É o estágio final do processo de testes O sistema é testado com dados fornecidos pelo cliente Pode revelar erros na definição dos requisitos

16 2.4. Evolução do software A flexibilidade dos sistemas de software é uma das principais razões pelas quais os softwares vem sendo, cada vez mais, incorporados em sistemas grandes e complexos. Uma vez que a decisão pela fabricação do hardware foi tomada, é muito caro fazer alterações em seu projeto. Entretanto, as mudanças no software podem ser feitas a qualquer momento durante ou após o desenvolvimento do sistema. Mesmo grandes mudanças são muito mais baratas do que as correspondentes alterações no hardware. Historicamente sempre houve uma separação entre processo de desenvolvimento e processo de evolução do software. As pessoas pensam no desenvolvimento como uma atividade criativa de um sistema a partir de um conceito inicial. A distinção entre desenvolvimento e manutenção é cada vez mais irrelevante. Poucos sistemas são completamente novos. Faz muito mais sentido ver o desenvolvimento e a evolução como processos contínuos. 3. Lidando com Mudanças Existem duas abordagens que podem ser adotadas para redução de custos de retrabalho: 1. Prevenção de mudanças Capacidade do software de se antecipar a mudanças Usar protótipos é uma boa para refinar requisitos. 2. Tolerância a mudanças Processo projetado de forma que mudanças possam ser acomodadas a custo relativamente baixo. O desenvolvimento incremental é uma das estratégias. 3.1 Prototipação Protótipo é uma versão inicial de um sistema de software. Serve para demonstrar conceitos e experimentar opções de projeto Serve para descobrir sobre problemas e suas possíveis soluções O desenvolvimento rápido e iterativo de protótipos é essencial para o controle de custos

17 Permite que usuários possam experimentar o sistema no início do processo Um protótipo de software pode ser usado em um processo de desenvolvimento para ajudar a antecipar mudanças que podem ser requisitadas: 1. No processo de engenharia de requisitos, pode ajudar na elicitação e validação dos requisitos de sistema 2. No processo de projeto de sistema, pode ser usado para estudar soluções específicas do software e para apoiar o projeto de interface com o usuário Pontos de atenção com protótipos: 1. Protótipos quase sempre não se preocupam com requisitos não funcionais 2. Um protótipo pode deixar transparecer que o problema é mais fácil de ser resolvido do que realmente o é. 3. Protótipos podem ser feitos em papel ou ferramentas específicas. 4. O cuidado com o tempo gasto na realização de protótipos Entrega incremental As entregas das partes do software são feitas de maneira incremental para o cliente. Eles identificam quais os serviços são mais importantes. Uma série de incrementos são definidos. Primeiros incrementos agem como protótipos.

18 Exercícios 1. Qual é o modelo mais eficaz para o desenvolvimento de sistemas de software de negócio? Por quê? 2. qual é o modelo mais eficaz para a construção de um sistema crítico de tempo real? Por quê? 3. Observe os cenários: Cenário 1: Precisamos desenvolver uma solução de matrícula online para uma universidade. Temos uma infraestrutura razoável com base em software livre. Temos uma equipe de analistas e desenvolvedores de tamanho médio. Já existe um banco de dados com todos os estudantes, cursos, disciplinas, etc. Cenário 2: Nossa equipe de analistas e gestores precisa de um sistema para controle dos projetos que desenvolvimentos. Temos todas as informações referentes as projetos em documentos de texto, planilhas, em nossas cabeças. Todo projeto tem cliente, prazo, custos, materiais, etc De acordo com os cenários apresentados desenvolva um ensaio com: Características gerais para a solução dos dois cenários em cada um dos três modelos de processo de software. Quais os comportamentos possíveis em cada um deles? Qual a melhor estratégia para cada um dos cenários? Seminários I. Tópicos abordados: Ciclo de vida, processos ágeis, processo unificado. 1. Metodologias de desenvolvimento de software 1.1. Desenvolvimento Ágil de Software 1.2. Processo unificado Realizar um trabalho comparativo entre as metodologias com base no Capítulo 3 Sommerville e Capítulo 3 Pressman. Relatório com 5 a 12 páginas. Constando: Resumo, Introdução, Conteúdo (Características, Diretrizes, Práticas e Métodos), Estudo de caso com base em um dos cenários. Conclusão.

19 Bibliografia Pompilho, S. (2002). Análise Essencial - guia prático de Análise de Sistemas. Rio de Janeiro: Ciência Moderna. Pressman, R. S. (2011). Engenharia de Software: Uma abordagem profissional. São Paulo: Bookman. Rosini, A. M. (2014). Administração de Sistemas de Informação e a Gestão do Conhecimento. São Paulo: Cengage Learning. Sommerville, I. (2011). Engenharia de Software 9a Ed. São Paulo: Pearson.