Define Dsi- processo cujo objectivo é introduzir mudanças num SI com o objectivo de melhorar o seu desempenho. Entre as alterações que são normalmente efectuadas, inclui- se a adopção de sistemas informáticos para suportar actividades organizacionais.

Faça uma descrição sucinta da perspectiva histórica do Dsi- Nas décadas de 50 e 60, não havia nenhum processo definido para DSI. A preocupação era descrever a solução em termos computacionais sem dar atenção à compreensão e descrição do sistema em SI, causando problemas como: insatisfação dos utilizadores, pois as suas necessidades não eram satisfeitas pelos novos sistemas operacionais, falta de documentação, (desactualizada) dificultando a manutenção dos sistemas desenvolvidos. FLYNN (1998) refere duas aproximações ao DSI: Uma aproximação HARD, que assume que o problema a resolver tem uma base lógica ou matemática e que um sistema informático é uma solução viável na maior parte dos casos. Outra aproximação SOFT, relacionada com os efeitos ambientais do SI, com os aspectos sociais, económicos, legais e psicológicos do ambiente, para a qual o sistema é desenvolvido.

Descreve e identifique o ciclo de vida do Dsi-

DESENVOLVIMENTO SEQÜENCIAL: segue uma abordagem sistemática e linear ao longo da vida do projecto, avançando o desenvolvimento de uma fase para outra, sequencialmente. O sistema estará pronto no final de todas as fases. Ex: Modelo em Cascata.

DESENVOLVIMENTO EVOLUTIVO: o sistema é construído em diferentes etapas, sendo, em cada uma, construída uma versão do sistema que vai evoluindo. Cada versão satisfaz os requisitos conhecidos, sendo avaliada pelo cliente final que ajuda a clarificar e detalhar os requisitos que vão levar à construção de uma nova versão. Ex: O Modelo Espiral.

DESENVOLVIMENTO INCREMENTAL: baseia-se na ideia de que se pode construir um sistema em várias versões, cada uma com um conjunto específico de funções. Na primeira versão, são desenvolvidas as funções mais importantes. Esta versão é utilizada e avaliada pelo cliente final, desenvolvendo -se um novo plano para o próximo incremento. O processo é repetido após cada incremento, até que o sistema completo esteja construído.

Descreve sucintamente os modelos de paradigmas do Dsi-

MODELO EM CASCATA: foi o primeiro paradigma que veio tentar disciplinar e sistematizar o DSI. Este modelo representado é normalmente designado por ciclo convencional de desenvolvimento de sistemas de informação. Cada fase tem objectivos bem definidos, nomeadamente: O estudo de viabilidade que consiste em analisar o problema existente e, de uma forma breve, apontar soluções alternativas; A identificação de requisitos que consiste em fazer uma recolha exaustiva de informação sobre o sistema a desenvolver; A análise detalhada que consiste em desenvolver uma especificação dos requisitos levantados na fase anterior; O desenho que desenvolve a arquitectura do sistema, especificando as suas componentes, o modelo físico de dados e os seus algoritmos; A codificação que visa traduzir as especificações obtidas na fase de desenho para uma linguagem de programação. Criar documentação, tal como manuais do utilizador e de instalação; A implantação de testes que consiste em executar teste ao sistema resultante; A manutenção que consiste em fazer as alterações necessárias durante a vida do sistema, quer sejam correcções a erro s existentes, quer alterações resultantes de novos requisitos.

PROTOTIPAGEM: Um protótipo é uma versão experimental de um sistema, construído com o objectivo de ser explorado, experimentado e avaliado. Uma primeira versão do sistema é construída sendo melhorada através de sucessivas iterações até que reflicta correctamente o sistema requerido. Estas sucessivas iterações consistem em verificações por parte dos utilizadores do sistema, sugerindo alterações a introduzir,

1

se necessário. A prototipagem permite aumentar a participação e interesse dos utilizadores no processo de desenvolvimento e construir sistemas em que os requisitos, a priori estão mal definidos, ajudando na definição e clarificação dos mesmos. É também um excelente contributo para o desenho da interface.

MODELO V: define um conjunto de fases e ordena-as. Neste modelo, o processo de DSI é basicamente dividido em duas partes, as duas pernas do V, a parte da especificação e a da verificação e validação. Este paradigma de desenvolvimento sugere que nenhuma fase pode ser considerada completa, e a seguinte começar, até que o documento produzido esteja completo.

MODELO ESPIRAL: engloba várias iterações através de sucessivos ciclos, os quais lhe conferem a forma de espiral. O modelo define quatro actividades: Planeamento, Análise de risco, Engenharia e Avaliação. Cada ciclo representa uma sequência repetida de passos e começa com a identificação de objectivos e restrições. Tendo como base esta informação, o passo seguinte avalia as alternativas, determinando riscos para a fase que se segue. Uma das vantagens deste modelo é a consideração dos riscos em todas as etapas do processo, o que poderá permitir reduzir os riscos antes que eles se tornem problemáticos.

DESENVOLVIMENTO RÁPIDO DE APLICAÇÕES: assenta no pressuposto de que nem todos os requisitos podem necessariamente ser identificados e especificados antecipadamente. Alguns requisitos apenas aparecerão depois de os utilizadores usarem o sistema. Os requisitos não são vistos como definitivos, mas evoluem ao longo do tempo. Num projecto desenvolvido segundo a aproximação RAD, os requisitos são priorizados segundo o que é chamada a regra MoSCoW: M: requisitos sem os quais o sistema não é viável (M = Must have); S: requisitos necessários,para garantir um maior benefício, mas que não põem em causa osucesso do sistema (S = Shouldhave); C: requisitos que, se não forem implementados, não têm impacto no projecto; são implementados quando há tempo e recursos (C = Couldhave); W: requisitos que poderão nunca ser implementados; poderão sê-lo numa componente maistardia (W= Won'thave). Os quatro elementos chave do RAD são: O JAD, JointApplicationDevelopment, para identificar, representar e validar requisitos; A utilização de protótipos, que também auxilia no levantamento mais rápido de requisitos e que se enquadra na visão do RAD, segundo a qual os requisitos vão evoluindo, e os utilizadores não sabe bem o que querem até que vêem e experimentam o protótipo; A utilização de ferramentas CASE, ComputerRdded Software Engineeríng, para automatizar o processo de desenvolvimento do sistema, principalmente as tarefas que mais tempos ocupam, como, por exemplo, a criação da documentação e codificação; Um grande envolvimento do utilizador.

DESENVOLVIMENTO DE SI WEB: baseia-se na substituição da fase de codificação por uma fase designada por implementação incremental, que inclui uma etapa de validação com o cliente, devido à importância que a interface com o utilizador tem nestes sistemas.

NORMA ISO/IEC 12207: pretendia definir um enquadramento comum para o processo de DSI e descreve as principais componentes do processo de DSI, as suas ligações e as relações que governam as suas interacções. Engloba aspectos não considerados nos modelos anteriormente apresentados, como sejam, os relacionados com a compra e venda dos SIBC, e com a gestão e desenvolvimento da organização, dividindo o ciclo de vida do software em três processos: processos fundamentais, processos de suporte e processos organizacionais.

Descreve algumas fases do processo do Dsi, tais como, estudo da viabilidade, engenharia de requisitos, e levantamento de requisitos.

2

Um estudo de viabilidade é um estudo preliminar que pretende investigar as necessidades de informação dos utilizadores e avaliar soluções alternativas e recursos necessários, bem como os custos e benefícios da intervenção e, consequentemente, a sua viabilidade. O resultado deste estudo pode ser formalizado num documento escrito que inclui uma especificação preliminar e um plano de desenvolvimento. A viabilidade do sistema pode ser avaliada em termos: Organizacionais; Económicos; Técnicos; Operacionais. Um estudo de viabilidade inclui normalmente uma análise de custos e benefícios que podem ser tangíveis ou intangíveis.

ENGENHARIA DE REQUISITOS: determinar as necessidades e restrições do sistema em desenvolvimento, estabelecendo uma visão geral do sistema num dado contexto, sendo normalmente aceite que o principal produto é a especificação de requisitos que deve indicar o que o sistema deve fazer e não como fazer. Um requisito é uma condição que tem que se verificar para atingir os objectivos do sistema. A especificação de requisitos deve ser completa, consistente, modificável, não ambígua, e deve especificar quer os requisitos funcionais quer os não funcionais. Um requisito funcional diz respeito a uma condição que o sistema tem que ser capaz de executar, enquanto um requisito não funcional está relacionado com as características qualitativas do sistema, e especifica uma função desejável para o sistema. As fases do processo são: levantamento, análise e negociação, especificação e documentação e validação e verificação.

LEVANTAMENTO DE REQUISITOS: o objectivo é interiorizar o conhecimento sobre o sistema para o entender, permitindo e facilitando o diálogo com os utilizadores e possibilitando a recolha da informação necessária para construir a imagem do sistema em estudo. Análise de documentação, entrevistas, questionários e observação directa são as técnicas mais comuns.

Enumere e descreve, pelo menos, sete técnicas para levantamento de requisitos. ANÁLISE DE DOCUMENTAÇÃO: A consulta e estudo de diferentes documentos existentes na organização, tais como regulamentações governamentais, relatórios, impressos, etc., e que estão relacionados com o sistema de informação em causa é uma técnica que, de certo modo, se torna cómoda, pois os documentos são facilmente transportáveis e, portanto, podem ser estudados em qualquer lugar. No entanto, é vulgar encontrar-se nas organizações, grande número de documentos, os quais nem sempre estão actualizados, nem descrevem, com o pormenor necessário, os procedimentos da organização. A análise de documentação serve para dar ao analista uma visão geral do funcionamento da organização e, mais propriamente, do sistema em questão. ENTREVISTAS: As entrevistas são a técnica mais usada para recolher informação. Esta técnica só permite recolher informação relevante se for devidamente preparada. Numa entrevista, pretende -se saber a opinião do entrevistado sobre o sistema. Muitas vezes as opiniões são mais importantes do que os factos, pois, frequentemente, é através das opiniões que se descobrem os problemas. Há cinco passos a considerar quando se planeia uma entrevista: Recolher informação de base sobre a organização e sobre os possíveis entrevistados; Estabelecer os objectivos da entrevista; Decidir quem entrevistar; Preparar o entrevistado; Definir a estrutura e tipo de questões.

QUESTIONÁRIOS: permite obter determinados detalhes que não foram obtidos durante a entrevista ou permite filtrar e validar dados obtidos nas diferentes entrevistas. Também se usam questionários para fazer um levantamento a um grupo maior de utilizadores, para sentir os problemas e levantar aspectos importantes, antes de agendar as entrevistas.

OBSERVAÇÃO: é uma técnica muito usada e que permite observar directamente as pessoas na execução do seu trabalho, facilitando a identificação do tipo de suporte que elas necessitam de um SI. A observação directa pode inibir, alterando o comportamento das pessoas que estão a ser observadas, logo, pondo em

3

causa a fiabilidade dos dados obtidos por esta técnica. É importante que o observador seja bem aceite pelas pessoas a analisar e não tenha qualquer interferência no processo que elas executam. O analista, ao observar situações reais, pode concluir se os dados que já tinham compilado estavam correctos. Podem-se distinguir dois tipos de observação: passiva e participativa. Um observador participativo toma parte activa no processo que observa, enquanto um observador passivo não tem qualquer envolvimento no processo.

VOLUMES: implica uma análise numérica de dados relevantes à compreensão do sistema, tais como o número de fornecedores nos últimos anos, o número de encomendas solicitadas por dia, a percentagem de encomendas rejeitadas por dia, etc. Todos estes volumes permitem, não só realçar erros e problemas existentes bem como o crescimento do sistema.

CENÁRIOS : Os cenários podem ser definidos como histórias que explicam como o sistema é usado. São particularmente úteis para acrescentar detalhes a uma prévia descrição de requisitos. Através de um cenário, o utilizador simula a sua interacção com o sistema, explicando ao analista o que faz e a informação de que necessita do sistema para executar a tarefa descrita no cenário. Um cenário deve incluir as seguintes informações: Descrição do estado do sistema antes de entrar no cenário; Fluxo de eventos no cenário; Excepções ao fluxo normal de eventos; Informação sobre outras actividades que podem ocorrer simultaneamente com o cenário; Descrição do estado do sistema depois de concluído o cenário.

PROTOTIPAGEM: Um protótipo de um sistema é uma versão inicial do sistema. Um dos objectivos da utilização de um protótipo é ajudar a levantar e validar requisitos. Os protótipos que têm este objectivo devem poder ser desenvolvidos rapidamente para estarem disponíveis no início do desenvolvimento. O protótipo permite que o utilizador experimente o sistema, percebendo como ele será usado para suportar o seu trabalho. Através da experimentação com o protótipo, os utilizadores poderão mais facilmente descobrir problemas e sugerir melhorias aos requisitos.

Descreve algumas falhas no processo do Dsi- A existência de um conjunto de etapas bem definidas do processo de DSI não evita que uma grande parte de projectos de DSI falhe na construção do sistema desejado, no tempo previsto e dentro do orçamento estimado. Há diferentes motivos apontados como causas destas falhas, dos quais se destaca o incompleto levantamento e especificação de requisitos, a falta de envolvimento e comunicação entre os stakeholders e a ênfase nos aspectos tecnológicos, em detrimento do contexto organizacional, e que, desde logo, sugerem que as fases iniciais são críticas no processo de DSI. Um outro motivo causador dos atrasos no processo de DSI é o baixo nível de reutilização de componentes. Um outro aspecto normalmente descurado no processo de DSI é a documentação do sistema. Qualquer sistema deve ser convenientemente documentado, de forma a permitir a sua utilização eficaz, bem como a sua manutenção. Consequentemente, devem ser criados dois tipos de documentos: Documentação do sistema; Manuais de utilizador. O uso apropriado de métodos de desenvolvimento de sistemas de informação e a gestão e controlo efectivo do processo de DSI são práticas que contribuem para a diminuição das falhas no processo de DSI.

Qual a importância para a modelação de dados no Dsi- SI que recorrem às TI não só melhoram a eficiência dos processos organizacionais, como também aumentam a efectividade e competitividade das organizações. Por esta razão, a maior parte das organizações tem de olhar de uma forma diferente para os SI, até no que diz respeito à forma do seu desenvolvimento. Para construir um SI que possa suportar e dar corpo à estratégia organização é necessária uma articulação multidisciplinar assente em observadores visionários da organização, projectistas, gestores, trabalhadores em e especialistas da área das TI. A organização é perspectivada no seu todo, para isso necessário recorrer aos seus modelos mais globais. A compreensão do SI na organização não deve partir de modelos 5, tais como Diagramas de Fluxo de Dados,

4

Diagramas de Classes, muito ares junto dos especialistas de TI, mas de modelos globais que sustentam decisões mais coerentes e integradas no seu todo que é a organização, permitindo responder a uma série de questões.

Os Tipos de métodos do Dsi são classificados de diferentes maneiras, sendo as classificações mais vulgares: Métodos estruturados e métodos orientados a objectos; Métodos orientados a processos, métodos orientados a dados e métodos híbridos; Métodos formais e semiformais; Métodos hard métodos soft. Descreve os métodos mencionados acima-

Os métodos estruturados apareceram para resolver os problemas do desenvolvimento onde a grande preocupação era escrever linhas de código sem previamente se pensar no problema. Os métodos estruturados caracterizam-se por usar princípios de decomposição como principal meio de lidar e reduzir a complexidade do problema em estudo.

Métodos orientados a processos e a dados recomendavam a construção de modelos, quer de dados, quer de processos, preocupando-se também com a consistência e a validação destes modelos.

Métodos híbridos são métodos que vêem os SI segundo três visões: processos, dados e tempo. Esta evolução das características relevantes num SI está evidentemente ligada à evolução do tipo de sistemas que, ao longo do tempo, foram sendo desenvolvidos. Por seu lado, os métodos orientados a objectos recorrem ao conceito de objecto como a principal unidade de modelação. Os objectos contêm quer dados quer serviços, operações, que manipulam os dados.

Os métodos formais recorrem a princípios próprios das áreas das engenharias e advogam o uso de modelos matemáticos para a especificação e validação dos SI. A dificuldade em manipular e ler os modelos matemáticos usados nesses métodos levou a que alguns incorporassem, nos últimos anos, notações gráficas.

Os métodos hard preocupam-se com os aspectos políticos, sociais e culturais do SI. O método soft preocupa-se com os processos, actividades, regras e produtos do SI, ou seja, os aspectos estruturais. Numa perspectiva ontológica, poder-se-á dizer que os métodos hard defendem uma descrição objectiva da realidade onde o desenvolvimento é mais formal e racional do que o defendido pelo s métodos soft. Estes últimos consideram que a realidade é interpretada de forma diferente pelas pessoas envolvidas na intervenção, uma vez que a realidade é socialmente construída.

Descreve a problemática dos métodos referenciados a alínea anterior.

Reconhece-se que há muitos métodos para o DSI o que provoca alguma confusão na área. As equipas que levam a cabo o DSI vêem-se confundidas sobre que método escolher. A utilização dos métodos, de acordo com as características do SI a ser desenvolvido, seria a situação desejável embora se reconheça pouco realista. Esta hipótese obrigaria as equipas de desenvolvimento a conhecerem todos os métodos para poderem escolher o mais adequado. Sabendo -se que o tempo associado à aprendizagem de um determinado método é um dos factores frequentemente apontado pelas organizações para a não adopção de métodos, leva a que se adopte uma situação mais realista. Os métodos não são escolhidos de acordo com as características do sistema a desenvolver, mas adaptam-se às características do sistema. Assim, surgem, na prática, várias personalizações de métodos o que ainda aumenta o portfólio de oferta de métodos a usar no DSI.

Faça a descrição de alguns métodos utilizados no Dsi, tais como: Estudo da viabilidade, Analise de requisitos, especificação de requisitos, especificação lógica, desenho físico, etc. ESTUDO DE

5

VIABILIDADE: O estudo de viabilidade visa estudar a área de interesse, de forma a providenciar informação sobre as necessidades da organização. Um projecto pode iniciar logo por esta etapa, quando não se acha necessário levar a cabo um estudo estratégico da organização. O estudo de viabilidade está dividido em quatro passos: preparar o estudo de viabilidade, definir o problema, identificar opções de viabilidade e construir o relatório de viabilidade.

ANÁLISE DE REQUISITOS: Este módulo está subdividido em duas etapas: estudo do ambiente actual e opções de negócio. A etapa estudo do ambiente actual subdivide-se em: definir o âmbito do projecto, desenvolver um modelo das actividades do negócio, desenvolver o modelo de fluxo de dados actual, desenvolver o modelo de dados actual, investigar e definir os requisitos, identificar os principais utilizadores do sistema e, finalmente, reunir os resultados do estudo. A etapa opções do negócio pretende, primeiro, apresentar diferentes alternativas para atingir os requisitos solicitados e, segundo, seleccionar das alternativas apresentadas a mais favorável. Esta etapa subdivide-se em dois passos: definição das opções de negócio e selecção da opção negócio.

ESPECIFICAÇÃO DE REQUISITOS: Neste módulo partindo da opção de negócio seleccionada, é criada uma especificação detalhada que o novo sistema satisfará. Este módulo está subdividido nos seguintes oito passos: desenvolver o modelo de fluxo de dados do sistema; desenvolver o modelo de dados do sistema proposto; definir as funções de actualização e de inquérito; identificar as interacções dos utilizadores com o sistema; desenvolver e definir o âmbito da prototipagem; desenvolver o modelo entidade-evento; confirmar os objectivos do sistema; reunir a especificação de requisitos.

ESPECIFICAÇÃO LÓGICA: Este módulo consiste em duas etapas paralelas: opções técnicas do sistema e desenho lógico. A primeira pretende definir a forma de, fisicamente, implementar a especificação de requisitos e a segunda pretende detalhar com mais pormenor o sistema. A especificação técnica do sistema subdivide-se em definir as opções técnicas e seleccionar uma opção técnica. A etapa de desenho lógico tem como objectivo criar uma especificação lógica do sistema, definida pelas opções de negócio. Esta etapa está subdividida em três passos: desenvolver os modelos de processamento de actualização e de inquérito, documentando operações, condições e erros, desenvolver o modelo de interface definindo a estrutura de menus, formatos de ecrãs e respectiva navegação e automatizar o modelo de dados.

DESENHO FÍSICO: Neste módulo, a partir da especificação lógica do sistema, é criado o desenho físico da base de dados, bem como as especificações de todos os programas para executar todas as funções requeridas. Inicialmente, é criado um primeiro desenho físico, que possa ser implantado recorrendo a qualquer base de dados, sendo este depois convertido para o sistema de base de dados seleccionado. Este módulo está subdividido em sete passos: preparar o desenho físico; criar o desenho físico dos dados; criar o mapa de implementação dos componentes lógicos de cada função; optimizar o desenho físico dos dados; completar as especificações das funções; consolidar a interfaces dados/processos; reunir o desenho físico.

RUP: foi desenvolvido com o objectivo de assegurar a produção de sistemas com qualidade e de poder ser usado num grande número de projectos e organizações. O RUP é suportado pela ferramenta CASE Rational e visa a construção de um SIBC, baseando -se em seis melhores práticas.

CONCEPÇÃO: visa em conjunto com as pessoas interessadas acordar os objectivos do sistema em estudo. É também objectivo desta fase planear, avaliar riscos, custos i vantagens do projecto em causa. No final desta fase, as pessoas envolvidas no projecto aprovam definição do objectivo do sistema, os custos estimados e as prioridades definida no desenvolvimento do projecto.

6

ELABORAÇÃO: O domínio do problema é analisado e detalhado nesta fase. É necessário ter uma compreensão profunda e global do sistema, identificando todos os requisitos funcionais e não funcionais. O diagrama de caso de uso é completado detalhado, descrevendo-se todos os casos de uso. A arquitectura do sistema, bem como as suas componentes são definidas.

CONSTRUÇÃO: Poder-se-á dizer que esta é a fase de fabricação; os componentes são desenvolvidos e integrados num produto final, sendo cuidadosamente testados. Nesta fase, visa-se optimizar os recursos, minimizando custos e atingir a qualidade e os prazos desejáveis. No final desta fase, pretende -se, não só ter o produto final, o sistema informático, pronto, como também os manuais dos utilizadores.

TRANSIÇÃO: Nesta fase, visa-se a passagem do produto construído para a comunidade aos seus utilizadores. Desta forma, é feita a substituição do sistema antigo pelo novo, geralmente, a conversão é feita em paralelo, as bases de dados são convertidas e os utilizadores são treinados, para que o sistema possa estar em operação. Nesta fase, geralmente, também se corrige alguns erros detectados e faz--se algumas alterações.

SSM foi desenvolvido visando resolver situações humanas, cujos problemas são não estruturados e incertos, sendo por isso classificado como um método soft. A ideia fundamental presente no SSM é que se pode mudar a forma de investigação em relação às metodologias tradicionais.

7