Introdução à Interdisciplinaridade e Requisitos na Educação

1 Para início de conversa Olá meu queridoa estudante 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 Lembre se seu comprometimento é a chave para seu sucesso profissional orientações da disciPlina Na unidade I vimos que a interdisciplinaridade permite ao estudante melhor compreensão da aplicação dos saberes uma visão holística organizacional e consequentemente atitudes proativas de pensar decidir e agir Nesta segunda unidade iremos abordar alguns elementos importantes acerca da definição e especificação de requisitos Iniciamos com o resultado de pesquisas e números que indicam a relevância do assunto Em seguida damos uma breve contextualizada sobre as atividades e conceitos da área Além de como objetivo da disciplina exercitaremos através de atividade prática o levantamento e documentação de requisitos Preparadoa Então vamos em frente Palavras do Professor Caroa estudante em função de um cenário econômico favorável as oportunidades de crescimento profissional estão ao alcance daqueles que além de possuírem competências e habilidades específicas necessárias em suas áreas de atuação detenham também conhecimentos gerais tornandoos ainda mais competitivos frente à concorrência interna e externa Ler bons livros e revistas variando a literatura acompanhar o noticiário através de jornais e sites desenvolve e aprimora o nosso senso crítico isto é a capacidade de ler e interpretar cenários a nossa volta e ao mesmo tempo nos posicionar de maneira efetiva e contundente quer a favor quer contra ou ainda com uma postura neutra Um hábito necessário para nos manter informado acerca de tantos acontecimentos ocorridos em lugares e áreas distintas Pois é caroa estudante O seu desempenho é importante para nós e para sua profissão 2 Guarde essa ideia O conhecimento é construído pela relação das informações obtidas portanto devemos criar os meios para facilitar estas associações Desta forma através do diálogo que estabelecemos entre as disciplinas e entre os sujeitos das ações durante o seu curso a multidisciplinaridade devolve a identidade das disciplinas fortalecendoas Palavras do Professor E aqui é o local reservado para isso Vamos revisar e praticar uma das mais importantes atividades realizadas pelos Analistas e Desenvolvedores de Sistemas profissionais Seguimos a diante o seu tutor estará à disposição para orientálo e acompanhálo nesta tarefa Você imaginou de onde surgem as funções que utilizamos em um sistema Quem as determina Como são selecionadas Quando um cliente pede para construirmos um novo sistema ele tem alguma noção do que o sistema fará Frequentemente o novo sistema substituirá um já existente ou o modo de realizar funções Algumas vezes o novo sistema é um aprimoramento ou uma extensão de um sistema atual Cada vez mais o sistema proposto é planejado para tarefas que nunca haviam sido realizadas antes adequar às notícias eletrônicas de acordo com os interesses dos clientes monitorar o nível de açúcar no sangue de um diabético e automaticamente controlar a dosagem de insulina fica a dica Caroa estudante não importa se a sua funcionalidade é nova ou antiga cada sistema tem um proposito geralmente expresso em termos do que o sistema pode fazer Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir os seus objetivos Inicialmente trabalhamos com nossos clientes para obter os requisitos fazendolhes perguntas demonstrando sistemas semelhantes ou até mesmo desenvolvendo protótipos das interfaces e funções do sistema solicitado Em seguida documentamos todos esses requisitos que ficarão registrados e serão utilizados para firmar o acordo entre as partes 3 você sabia Você sabia que os requisitos são primeiro escritos de tal maneira que nós e nossos clientes possamos chegar a um acordo sobre o que o sistema deverá fazer Pois é os requisitos são reescritos geralmente em uma representação mais matemática de tal maneira que os projetistas possam transformar os requisitos em um bom projeto do sistema Uma determinada etapa de verificação assegura que os requisitos estejam completos corretos e consistentes e em seguida existe uma etapa de validação que garante que o cliente pretende ver no produto final Caroa estudante o ambiente de Desenvolvimento de Aplicações é uma áreas das mais complexas onde se realizam projetos e seus índices de fracasso são muito altos Há relatos desde o surgimento do computador na década de 50 este fato sacrifica os envolvidos com projetos de TI Desde então muito tem sido feito para se melhorar os resultados desta área entretanto as pesquisas realizadas tem mostrado ligeira melhora veja os resultados do Standish Group fornecidos no Chaos Report leitura comPlementar Clique aqui e tenha acesso ao relatório de 2014 O relatório de 2013 aponta que apenas 39 dos projetos de TI no mundo alcançam sucesso Fonte CHAOS Manifesto 2013 The Standish Group Em dados obtidos sobre mesma pesquisa realizada em 1994 indica ainda que as principais causas de fracasso são Requisitos Incompletos 131 Falta de envolvimento do usuário 124 Falta de recursos 106 Expectativas não realistas 99 Falta de apoio executivo 93 Mudanças de requisitos 87 Falta de planejamento 81 Não precisa mais daquilo 75 Falta de gestão da TI 62 Analfabetismo tecnológico 43 4 Para combater o fracasso o próprio Standish Group aponta um conjunto mais consistente de fatores críticos de sucesso para projetos de TI Apoio à gestão executiva Envolvimento do usuário Optimização Recursos qualificados Conhecimentos de gerenciamento de projetos Processo ágil Objetivo claro de negócios Maturidade emocional Execução Ferramentas e infraestrutura Já em uma pesquisa sobre maturidade em sucesso em gerenciamento de projetos de sistema de informação realizada no Brasil em 2010 tal como nas de 2006 e 2008 os participantes foram solicitados a apontar até três principais causas de fracasso de seus projetos conforme a seguinte lista de causas de fracasso a Estudo de Viabilidade ou Business Case ou Business Plan incompleto ou incorreto b Frequentes mudanças de escopo c Frequentes alterações de prioridade entre os projetos da carteira vindas da alta administração d Prazos inexequíveis e Tamanho da carteira de projetos muito além da capacidade de atendimento do setor f Comprometimento insuficiente ou inadequado das áreas envolvidas g Comprometimento insuficiente ou inadequado da alta administração h Falta de recursos humanos financeiros e materiais i Precariedade de método ferramentas e técnicas para o gerenciamento dos projetos j Insuficiente capacidade gerencial dos Gerentes de Projetos k Habilidade técnica da equipe em TI insuficiente ou inadequada para os desafios l Riscos não adequadamente gerenciados Os resultados mostraram que as principais causas de fracasso são as seguintes conforme podemos observar também pela figura abaixo 5 Fonte Maturidade Brasil 2010 leitura comPlementar Todos os detalhes da pesquisa podem ser encontrados clicando aqui fica a dica Meu caroa observe que algumas partes do processo de identificação definição e gerenciamento de requisitos estão envolvidos em quase todas essas causas A falta de cuidado com o entendimento a documentação e o gerenciamento dos requisitos podem levar a uma grande quantidade de problemas a construção de um sistema que resolve o problema errado que não funciona como esperado ou que é difícil para os usuários entenderem e utilizarem Além disso um processo de requisitos ineficiente pode custar caro Assim vale a pena utilizar algum tempo para entender o problema e seu contexto e obter os requisitos na primeira vez Geralmente é útil separar os requisitos em três categorias 1 Requisitos que devem ser totalmente satisfeitos 2 Requisitos que são altamente desejáveis mas não necessários 3 Requisitos que são possíveis mas poderiam ser eliminados 6 Por exemplo um sistema de cobrança de cartões de crédito deve ser capaz de relacionar as despesas atuais somalas e solicitar o pagamento para uma certa data Esses são os requisitos da categoria 1 Mas ele também pode separar as despesas por tipo de compra para auxiliar o comprador a entender os padrões de compra A análise do tipo de compra é provavelmente um requisito da categoria 2 Finalmente o sistema de cobrança pode imprimir os créditos em preto e os débitos em vermelho mas esse requisito provavelmente se enquadra na categoria 3 Palavras do Professor Observe que nenhum desses requisitos especifica como o sistema será implementado Em outras palavras não há nenhuma menção de qual sistema de gerenciamento de banco de dados será utilizado do volume de memória que o computador deverá ter ou sobre que linguagem de programação deverá ser utilizada para desenvolver o sistema Essas restrições especificas da implementação não são consideradas nos requisitos a menos que o cliente exija Pois isto é assunto para a próxima unidade Dizemos que os requisitos identificam o que o sistema deve fazer e o projeto identifica como E então o que você está achando até agora Você precisa de ajuda para entender algum trecho Sinalize o seu tutor ele lhe ajudará no que for preciso Vamos continuar dois tiPos de documento de reQuisitos Como o enfoque é no problema do cliente a identificação e a análise dos requisitos servem para propósitos distintos porém relacionados Por um lado a identificação dos requisitos nos habilita a escrever um documento de definição de requisitos Escrita de maneira que o cliente possa entender a definição dos requisitos é uma listagem completa de tudo que o cliente espera que o sistema proposto faça Ela representa um consenso entre o cliente e o desenvolvedor sobre o que o cliente precisa ou quer e é geralmente escrita em conjunto Por outro lado a especificação de requisitos os redefine em termos técnicos apropriados para o desenvolvimento do projeto do sistema Ela é a definição técnica do documento dos requisitos e é escrita pelos analistas de requisitos Algumas vezes um único documento pode servir para ambos os propósitos levando a um entendimento comum entre clientes analistas de requisitos e projetistas Os requisitos descrevem o comportamento de um sistema À medida que o sistema atua nos dados ou nas instruções objetos ou entidades se movem de um estado para outro por exemplo de vazio para cheio de ocupado para desocupado de envio para recebimento Em particular os requisitos descrevem atividades do sistema tais como uma reação a inserção de dados e o estado de cada entidade antes e depois de a atividade ocorrer 7 Para nos ajudar a descrever os requisitos podemos classificalos de duas maneiras funcionais e não funcionais Um requisito funcional descreve uma interação entre o sistema e seu ambiente Podemos utilizar várias técnicas para determinar os requisitos funcionais incluindo os casos de uso forma mais frequentemente utilizada entre os analistas de sistemas leitura comPlementar Clique aqui e apenas siga adiante após a leitura do conteúdo Caroa estudante uma maneira conveniente de se determinar os requisitos funcionais de um sistema é identificar seus casos de uso Os casos de uso dividem o sistema em um conjunto de partes lógicas minimamente relacionadas cada uma das quais descrevendo um modo de funcionamento do sistema Algumas das vantagens na visualização do sistema em termos de casos de uso são Como existem poucas conexões de um caso de uso para outro podemos examinar cada caso de uso separadamente e entendêlos sem precisar conhecer todos os detalhes do sistema mais amplo Podemos utilizar os casos de uso como base para estimar quanto tempo e esforço serão necessários para o projeto e a codificação do sistema O desenvolvimento do sistema pode ser controlado em termos de casos de uso Isto é os gerentes podem acompanhar o progresso de cada caso de uso à medida que o sistema é projetado codificado e testado leitura comPlementar Clique aqui e veja os casos de uso levantados sua descrição e as relações estabelecidas através do diagrama de caso de uso para um sistema de vendas Já quando falamos de requisitos nãofuncionais os mesmos colocam restrições no sistema que estamos a desenvolver Isto é eles descrevem uma ou mais restrições no sistema que limitam as opções para criar uma solução para o problema Por exemplo o tempo de resposta de uma consulta pode ser requisitado em uma quantidade determinada de segundos De maneira semelhante a solução poderá ter que funcionar em um sistema operacional com versão especifica ou até relacionandose com periféricos apropriados para execução daquelas atividades Essas restrições geralmente limitam nossa seleção referente à linguagem plataforma técnicas ou ferramentas de implementação Todavia a seleção é feita no estágio de projeto depois que os requisitos tenham sido especificados 8 Palavras do Professor Meu caroa toda essa contextualização é para preparalos para a prática A teoria sobre este conteúdo você deve ter adquirido durante o curso nas diversas disciplinas que foram oferecidas Contudo há diversas habilidades que são importantes que você domine É essencial que você separe o problema da solução Existem requisitos funcionais e nãofuncionais Há muitos tipos diferentes de técnicas de definição e especificação atividade avaliativa No guia da Unidade 1 você foi desafiado a encontrar um problema ou necessidade e propor uma solução tecnológica Portanto utilize como referência a solução apresentada e agora teremos que detalhar um conjunto de funções ou seja os requisitos funcionais que deverão estar contidos na solução assim como as restrições ou requisitos nãofuncionais e os diagramas de caso de uso desta solução que são representados pelos elementos de modelo básico Ator Caso de Uso Associações Caso tenha alguma dificuldade neste momento para criação do diagrama de Caso de Uso espere até a Unidade 3 lá você terá mais informações que podem lhe ajudar na criação no entanto não esqueça de retornar a sua Atividade Avaliativa 2 e incluilos Foi disponibilizado o Documento de Requisitos nos materiais desta disciplina como Atividade Contextualizada É neste documento que você estudante deverá documentar o que foi requisitado Para resumir Para resumir neste guia mostramos a importância do processo de identificação de requisitos De forma que ele não é realizado 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 Encerramos neste momento todo o conteúdo da Unidade II É importante que você tenha compreendido todo o assunto pois ele é a base para compreensão das unidades seguintes Na Unidade III veremos com mais detalhes o conteúdo proposto iremos abordar os elementos importantes acerca do projeto de sistemas Caso tenha alguma dúvida você deve entrar em contato com o tutor para que as esclareça Bom estudo