Define Dsi- processo cujo objectivo introduzir mudanas num SI com o objectivo de melhorar o seu desempenho.

. Entre as alteraes que so normalmente efectuadas, inclui- se a adopo de sistemas informticos para suportar actividades organizacionais. Faa uma descrio sucinta da perspectiva histrica do Dsi- Nas dcadas de 50 e 60, no havia nenhum processo definido para DSI. A preocupao era descrever a soluo em termos computacionais sem dar ateno compreenso e descrio do sistema em SI, causando problemas como: insatisfao dos utilizadores, pois as suas necessidades no eram satisfeitas pelos novos sistemas operacionais, falta de documentao, (desactualizada) dificultando a manuteno dos sistemas desenvolvidos. FLYNN (1998) refere duas aproximaes ao DSI: Uma aproximao HARD, que assume que o problema a resolver tem uma base lgica ou matemtica e que um sistema informtico uma soluo vivel na maior parte dos casos. Outra aproximao SOFT, relacionada com os efeitos ambientais do SI, com os aspectos sociais, econmicos, legais e psicolgicos do ambiente, para a qual o sistema desenvolvido. Descreve e identifique o ciclo de vida do DsiDESENVOLVIMENTO SEQENCIAL: segue uma abordagem sistemtica e linear ao longo da vida do projecto, avanando 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 construdo em diferentes etapas, sendo, em cada uma, construda uma verso do sistema que vai evoluindo. Cada verso satisfaz os requisitos conhecidos, sendo avaliada pelo cliente final que ajuda a clarificar e detalhar os requisitos que vo levar construo de uma nova verso. Ex: O Modelo Espiral. DESENVOLVIMENTO INCREMENTAL: baseia-se na ideia de que se pode construir um sistema em vrias verses, cada uma com um conjunto especfico de funes. Na primeira verso, so desenvolvidas as funes mais importantes. Esta verso utilizada e avaliada pelo cliente final, desenvolvendo -se um novo plano para o prximo incremento. O processo repetido aps cada incremento, at que o sistema completo esteja construdo. Descreve sucintamente os modelos de paradigmas do DsiMODELO 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 informao. Cada fase tem objectivos bem definidos, nomeadamente: O estudo de viabilidade que consiste em analisar o problema existente e, de uma forma breve, apontar solues alternativas; A identificao de requisitos que consiste em fazer uma recolha exaustiva de informao sobre o sistema a desenvolver; A anlise detalhada que consiste em desenvolver uma especificao dos requisitos levantados na fase anterior; O desenho que desenvolve a arquitectura do sistema, especificando as suas componentes, o modelo fsico de dados e os seus algoritmos; A codificao que visa traduzir as especificaes obtidas na fase de desenho para uma linguagem de programao. Criar documentao, tal como manuais do utilizador e de instalao; A implantao de testes que consiste em executar teste ao sistema resultante; A manuteno que consiste em fazer as alteraes necessrias durante a vida do sistema, quer sejam correces a erro s existentes, quer alteraes resultantes de novos requisitos. PROTOTIPAGEM: Um prottipo uma verso experimental de um sistema, construdo com o objectivo de ser explorado, experimentado e avaliado. Uma primeira verso do sistema construda sendo melhorada atravs de sucessivas iteraes at que reflicta correctamente o sistema requerido. Estas sucessivas
1

iteraes consistem em verificaes por parte dos utilizadores do sistema, sugerindo alteraes a introduzir, se necessrio. A prototipagem permite aumentar a participao e interesse dos utilizadores no processo de desenvolvimento e construir sistemas em que os requisitos, a priori esto mal definidos, ajudando na definio e clarificao dos mesmos. tambm 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 especificao e a da verificao e validao. Este paradigma de desenvolvimento sugere que nenhuma fase pode ser considerada completa, e a seguinte comear, at que o documento produzido esteja completo. MODELO ESPIRAL: engloba vrias iteraes atravs de sucessivos ciclos, os quais lhe conferem a forma de espiral. O modelo define quatro actividades: Planeamento, Anlise de risco, Engenharia e Avaliao. Cada ciclo representa uma sequncia repetida de passos e comea com a identificao de objectivos e restries. Tendo como base esta informao, o passo seguinte avalia as alternativas, determinando riscos para a fase que se segue. Uma das vantagens deste modelo a considerao dos riscos em todas as etapas do processo, o que poder permitir reduzir os riscos antes que eles se tornem problemticos. DESENVOLVIMENTO RPIDO DE APLICAES: assenta no pressuposto de que nem todos os requisitos podem necessariamente ser identificados e especificados antecipadamente. Alguns requisitos apenas aparecero depois de os utilizadores usarem o sistema. Os requisitos no so vistos como definitivos, mas evoluem ao longo do tempo. Num projecto desenvolvido segundo a aproximao RAD, os requisitos so priorizados segundo o que chamada a regra MoSCoW: M: requisitos sem os quais o sistema no vivel (M = Must have); S: requisitos necessrios,para garantir um maior benefcio, mas que no pem em causa osucesso do sistema (S = Shouldhave); C: requisitos que, se no forem implementados, no tm impacto no projecto; so implementados quando h tempo e recursos (C = Couldhave); W: requisitos que podero nunca ser implementados; podero s-lo numa componente maistardia (W= Won'thave). Os quatro elementos chave do RAD so: O JAD, JointApplicationDevelopment, para identificar, representar e validar requisitos; A utilizao de prottipos, que tambm auxilia no levantamento mais rpido de requisitos e que se enquadra na viso do RAD, segundo a qual os requisitos vo evoluindo, e os utilizadores no sabe bem o que querem at que vem e experimentam o prottipo; A utilizao de ferramentas CASE, ComputerRdded Software Engineerng, para automatizar o processo de desenvolvimento do sistema, principalmente as tarefas que mais tempos ocupam, como, por exemplo, a criao da documentao e codificao; Um grande envolvimento do utilizador. DESENVOLVIMENTO DE SI WEB: baseia-se na substituio da fase de codificao por uma fase designada por implementao incremental, que inclui uma etapa de validao com o cliente, devido importncia 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 ligaes e as relaes que governam as suas interaces. Engloba aspectos no considerados nos modelos anteriormente apresentados, como sejam, os relacionados com a compra e venda dos SIBC, e com a gesto e desenvolvimento da organizao, dividindo o ciclo de vida do software em trs 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. Um estudo de viabilidade um estudo preliminar que pretende investigar as necessidades de informao dos utilizadores e avaliar solues alternativas e recursos necessrios, bem como os custos e benefcios da interveno e, consequentemente, a sua viabilidade. O resultado deste estudo pode ser formalizado num documento escrito que inclui uma especificao preliminar e um plano de desenvolvimento. A viabilidade do sistema pode ser avaliada em termos: Organizacionais; Econmicos; Tcnicos; Operacionais. Um estudo de viabilidade inclui normalmente uma anlise de custos e benefcios que podem ser tangveis ou intangveis. ENGENHARIA DE REQUISITOS: determinar as necessidades e restries do sistema em desenvolvimento, estabelecendo uma viso geral do sistema num dado contexto, sendo normalmente aceite que o principal produto a especificao de requisitos que deve indicar o que o sistema deve fazer e no como fazer. Um requisito uma condio que tem que se verificar para atingir os objectivos do sistema. A especificao de requisitos deve ser completa, consistente, modificvel, no ambgua, e deve especificar quer os requisitos funcionais quer os no funcionais. Um requisito funcional diz respeito a uma condio que o sistema tem que ser capaz de executar, enquanto um requisito no funcional est relacionado com as caractersticas qualitativas do sistema, e especifica uma funo desejvel para o sistema. As fases do processo so: levantamento, anlise e negociao, especificao e documentao e validao e verificao. LEVANTAMENTO DE REQUISITOS: o objectivo interiorizar o conhecimento sobre o sistema para o entender, permitindo e facilitando o dilogo com os utilizadores e possibilitando a recolha da informao necessria para construir a imagem do sistema em estudo. Anlise de documentao, entrevistas, questionrios e observao directa so as tcnicas mais comuns. Enumere e descreve, pelo menos, sete tcnicas para levantamento de requisitos. ANLISE DE DOCUMENTAO: A consulta e estudo de diferentes documentos existentes na organizao, tais como regulamentaes governamentais, relatrios, impressos, etc., e que esto relacionados com o sistema de informao em causa uma tcnica que, de certo modo, se torna cmoda, pois os documentos so facilmente transportveis e, portanto, podem ser estudados em qualquer lugar. No entanto, vulgar encontrar-se nas organizaes, grande nmero de documentos, os quais nem sempre esto actualizados, nem descrevem, com o pormenor necessrio, os procedimentos da organizao. A anlise de documentao serve para dar ao analista uma viso geral do funcionamento da organizao e, mais propriamente, do sistema em questo. ENTREVISTAS: As entrevistas so a tcnica mais usada para recolher informao. Esta tcnica s permite recolher informao relevante se for devidamente preparada. Numa entrevista, pretende -se saber a opinio do entrevistado sobre o sistema. Muitas vezes as opinies so mais importantes do que os factos, pois, frequentemente, atravs das opinies que se descobrem os problemas. H cinco passos a considerar quando se planeia uma entrevista: Recolher informao de base sobre a organizao e sobre os possveis entrevistados; Estabelecer os objectivos da entrevista; Decidir quem entrevistar; Preparar o entrevistado; Definir a estrutura e tipo de questes. QUESTIONRIOS: permite obter determinados detalhes que no foram obtidos durante a entrevista ou permite filtrar e validar dados obtidos nas diferentes entrevistas. Tambm se usam questionrios para fazer um levantamento a um grupo maior de utilizadores, para sentir os problemas e levantar aspectos importantes, antes de agendar as entrevistas.

OBSERVAO: uma tcnica muito usada e que permite observar directamente as pessoas na execuo do seu trabalho, facilitando a identificao do tipo de suporte que elas necessitam de um SI. A observao directa pode inibir, alterando o comportamento das pessoas que esto a ser observadas, logo, pondo em causa a fiabilidade dos dados obtidos por esta tcnica. importante que o observador seja bem aceite pelas pessoas a analisar e no tenha qualquer interferncia no processo que elas executam. O analista, ao observar situaes reais, pode concluir se os dados que j tinham compilado estavam correctos. Podem-se distinguir dois tipos de observao: passiva e participativa. Um observador participativo toma parte activa no processo que observa, enquanto um observador passivo no tem qualquer envolvimento no processo. VOLUMES: implica uma anlise numrica de dados relevantes compreenso do sistema, tais como o nmero de fornecedores nos ltimos anos, o nmero de encomendas solicitadas por dia, a percentagem de encomendas rejeitadas por dia, etc. Todos estes volumes permitem, no s realar erros e problemas existentes bem como o crescimento do sistema. CENRIOS: Os cenrios podem ser definidos como histrias que explicam como o sistema usado. So particularmente teis para acrescentar detalhes a uma prvia descrio de requisitos. Atravs de um cenrio, o utilizador simula a sua interaco com o sistema, explicando ao analista o que faz e a informao de que necessita do sistema para executar a tarefa descrita no cenrio. Um cenrio deve incluir as seguintes informaes: Descrio do estado do sistema antes de entrar no cenrio; Fluxo de eventos no cenrio; Excepes ao fluxo normal de eventos; Informao sobre outras actividades que podem ocorrer simultaneamente com o cenrio; Descrio do estado do sistema depois de concludo o cenrio. PROTOTIPAGEM: Um prottipo de um sistema uma verso inicial do sistema. Um dos objectivos da utilizao de um prottipo ajudar a levantar e validar requisitos. Os prottipos que tm este objectivo devem poder ser desenvolvidos rapidamente para estarem disponveis no incio do desenvolvimento. O prottipo permite que o utilizador experimente o sistema, percebendo como ele ser usado para suportar o seu trabalho. Atravs da experimentao com o prottipo, os utilizadores podero mais facilmente descobrir problemas e sugerir melhorias aos requisitos. Descreve algumas falhas no processo do Dsi- A existncia de um conjunto de etapas bem definidas do processo de DSI no evita que uma grande parte de projectos de DSI falhe na construo do sistema desejado, no tempo previsto e dentro do oramento estimado. H diferentes motivos apontados como causas destas falhas, dos quais se destaca o incompleto levantamento e especificao de requisitos, a falta de envolvimento e comunicao entre os stakeholders e a nfase nos aspectos tecnolgicos, em detrimento do contexto organizacional, e que, desde logo, sugerem que as fases iniciais so crticas no processo de DSI. Um outro motivo causador dos atrasos no processo de DSI o baixo nvel de reutilizao de componentes. Um outro aspecto normalmente descurado no processo de DSI a documentao do sistema. Qualquer sistema deve ser convenientemente documentado, de forma a permitir a sua utilizao eficaz, bem como a sua manuteno. Consequentemente, devem ser criados dois tipos de documentos: Documentao do sistema; Manuais de utilizador. O uso apropriado de mtodos de desenvolvimento de sistemas de informao e a gesto e controlo efectivo do processo de DSI so prticas que contribuem para a diminuio das falhas no processo de DSI. Qual a importncia para a modelao de dados no Dsi- SI que recorrem s TI no s melhoram a eficincia dos processos organizacionais, como tambm aumentam a efectividade e competitividade das organizaes. Por esta razo, a maior parte das organizaes 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 estratgia organizao necessria uma articulao multidisciplinar assente em observadores
4

visionrios da organizao, projectistas, gestores, trabalhadores em e especialistas da rea das TI. A organizao perspectivada no seu todo, para isso necessrio recorrer aos seus modelos mais globais. A compreenso do SI na organizao no deve partir de modelos 5, tais como Diagramas de Fluxo de Dados, Diagramas de Classes, muito ares junto dos especialistas de TI, mas de modelos globais que sustentam decises mais coerentes e integradas no seu todo que a organizao, permitindo responder a uma srie de questes. Os Tipos de mtodos do Dsi so classificados de diferentes maneiras, sendo as classificaes mais vulgares: Mtodos estruturados e mtodos orientados a objectos; Mtodos orientados a processos, mtodos orientados a dados e mtodos hbridos; Mtodos formais e semiformais; Mtodos hard mtodos soft. Descreve os mtodos mencionados acimaOs mtodos estruturados apareceram para resolver os problemas do desenvolvimento onde a grande preocupao era escrever linhas de cdigo sem previamente se pensar no problema. Os mtodos estruturados caracterizam-se por usar princpios de decomposio como principal meio de lidar e reduzir a complexidade do problema em estudo. Mtodos orientados a processos e a dados recomendavam a construo de modelos, quer de dados, quer de processos, preocupando-se tambm com a consistncia e a validao destes modelos. Mtodos hbridos so mtodos que vem os SI segundo trs vises: processos, dados e tempo. Esta evoluo das caractersticas relevantes num SI est evidentemente ligada evoluo do tipo de sistemas que, ao longo do tempo, foram sendo desenvolvidos. Por seu lado, os mtodos orientados a objectos recorrem ao conceito de objecto como a principal unidade de modelao. Os objectos contm quer dados quer servios, operaes, que manipulam os dados. Os mtodos formais recorrem a princpios prprios das reas das engenharias e advogam o uso de modelos matemticos para a especificao e validao dos SI. A dificuldade em manipular e ler os modelos matemticos usados nesses mtodos levou a que alguns incorporassem, nos ltimos anos, notaes grficas. Os mtodos hard preocupam-se com os aspectos polticos, sociais e culturais do SI. O mtodo soft preocupa-se com os processos, actividades, regras e produtos do SI, ou seja, os aspectos estruturais. Numa perspectiva ontolgica, poder-se- dizer que os mtodos hard defendem uma descrio objectiva da realidade onde o desenvolvimento mais formal e racional do que o defendido pelo s mtodos soft. Estes ltimos consideram que a realidade interpretada de forma diferente pelas pessoas envolvidas na interveno, uma vez que a realidade socialmente construda. Descreve a problemtica dos mtodos referenciados a alnea anterior. Reconhece-se que h muitos mtodos para o DSI o que provoca alguma confuso na rea. As equipas que levam a cabo o DSI vem-se confundidas sobre que mtodo escolher. A utilizao dos mtodos, de acordo com as caractersticas do SI a ser desenvolvido, seria a situao desejvel embora se reconhea pouco realista. Esta hiptese obrigaria as equipas de desenvolvimento a conhecerem todos os mtodos para poderem escolher o mais adequado. Sabendo -se que o tempo associado aprendizagem de um determinado mtodo um dos factores frequentemente apontado pelas organizaes para a no adopo de mtodos, leva a que se adopte uma situao mais realista. Os mtodos no so escolhidos de acordo com as caractersticas do sistema a desenvolver, mas adaptam-se s caractersticas do sistema. Assim, surgem, na

prtica, vrias personalizaes de mtodos o que ainda aumenta o portflio de oferta de mtodos a usar no DSI. Faa a descrio de alguns mtodos utilizados no Dsi, tais como: Estudo da viabilidade, Analise de requisitos, especificao de requisitos, especificao lgica, desenho fsico, etc. ESTUDO DE VIABILIDADE: O estudo de viabilidade visa estudar a rea de interesse, de forma a providenciar informao sobre as necessidades da organizao. Um projecto pode iniciar logo por esta etapa, quando no se acha necessrio levar a cabo um estudo estratgico da organizao. O estudo de viabilidade est dividido em quatro passos: preparar o estudo de viabilidade, definir o problema, identificar opes de viabilidade e construir o relatrio de viabilidade. ANLISE DE REQUISITOS: Este mdulo est subdividido em duas etapas: estudo do ambiente actual e opes de negcio. A etapa estudo do ambiente actual subdivide-se em: definir o mbito do projecto, desenvolver um modelo das actividades do negcio, 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 opes do negcio pretende, primeiro, apresentar diferentes alternativas para atingir os requisitos solicitados e, segundo, seleccionar das alternativas apresentadas a mais favorvel. Esta etapa subdivide-se em dois passos: definio das opes de negcio e seleco da opo negcio. ESPECIFICAO DE REQUISITOS: Neste mdulo partindo da opo de negcio seleccionada, criada uma especificao detalhada que o novo sistema satisfar. Este mdulo 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 funes de actualizao e de inqurito; identificar as interaces dos utilizadores com o sistema; desenvolver e definir o mbito da prototipagem; desenvolver o modelo entidade-evento; confirmar os objectivos do sistema; reunir a especificao de requisitos. ESPECIFICAO LGICA: Este mdulo consiste em duas etapas paralelas: opes tcnicas do sistema e desenho lgico. A primeira pretende definir a forma de, fisicamente, implementar a especificao de requisitos e a segunda pretende detalhar com mais pormenor o sistema. A especificao tcnica do sistema subdivide-se em definir as opes tcnicas e seleccionar uma opo tcnica. A etapa de desenho lgico tem como objectivo criar uma especificao lgica do sistema, definida pelas opes de negcio. Esta etapa est subdividida em trs passos: desenvolver os modelos de processamento de actualizao e de inqurito, documentando operaes, condies e erros, desenvolver o modelo de interface definindo a estrutura de menus, formatos de ecrs e respectiva navegao e automatizar o modelo de dados. DESENHO FSICO: Neste mdulo, a partir da especificao lgica do sistema, criado o desenho fsico da base de dados, bem como as especificaes de todos os programas para executar todas as funes requeridas. Inicialmente, criado um primeiro desenho fsico, que possa ser implantado recorrendo a qualquer base de dados, sendo este depois convertido para o sistema de base de dados seleccionado. Este mdulo est subdividido em sete passos: preparar o desenho fsico; criar o desenho fsico dos dados; criar o mapa de implementao dos componentes lgicos de cada funo; optimizar o desenho fsico dos dados; completar as especificaes das funes; consolidar a interfaces dados/processos; reunir o desenho fsico. RUP: foi desenvolvido com o objectivo de assegurar a produo de sistemas com qualidade e de poder ser usado num grande nmero de projectos e organizaes. O RUP suportado pela ferramenta CASE Rational e visa a construo de um SIBC, baseando -se em seis melhores prticas.

CONCEPO: visa em conjunto com as pessoas interessadas acordar os objectivos do sistema em estudo. tambm objectivo desta fase planear, avaliar riscos, custos i vantagens do projecto em causa. No final desta fase, as pessoas envolvidas no projecto aprovam definio do objectivo do sistema, os custos estimados e as prioridades definida no desenvolvimento do projecto. ELABORAO: O domnio do problema analisado e detalhado nesta fase. necessrio ter uma compreenso profunda e global do sistema, identificando todos os requisitos funcionais e no 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 so definidas. CONSTRUO: Poder-se- dizer que esta a fase de fabricao; os componentes so 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 desejveis. No final desta fase, pretende -se, no s ter o produto final, o sistema informtico, pronto, como tambm os manuais dos utilizadores. TRANSIO: Nesta fase, visa-se a passagem do produto construdo para a comunidade aos seus utilizadores. Desta forma, feita a substituio do sistema antigo pelo novo, geralmente, a converso feita em paralelo, as bases de dados so convertidas e os utilizadores so treinados, para que o sistema possa estar em operao. Nesta fase, geralmente, tambm se corrige alguns erros detectados e faz--se algumas alteraes. SSM foi desenvolvido visando resolver situaes humanas, cujos problemas so no estruturados e incertos, sendo por isso classificado como um mtodo soft. A ideia fundamental presente no SSM que se pode mudar a forma de investigao em relao s metodologias tradicionais.