Desenvolvimento dos SI

Apresentação em tema: "Desenvolvimento dos SI"— Transcrição da apresentação:

1 Desenvolvimento dos SI
O processo de desenvolvimento Abordagens de desenvolvimento As fases: Concepção Análise Desenho Implementação Manutenção Alternativas para a construção de sistemas desenvolvimento Análise Construção Manutenção Desenho Concepção O desenvolvimento dos SI é a ciência e a arte de desenhar e elaborar de forma ordenada e controlada, sistemas de informação. Nas organizações modernas o desenvolvimento de sistemas é um processo organizacional chave. Nesta aula vamos a descrever as actividades envolvidas nesse processo e as diversas abordagens de desenvolvimento. Também vamos a ver as alternativas existentes para a construção de sistemas.

2 Arquitectura da Gestão dos SI
Análise Estratégica Implementação Estratégica Definição Estratégica Operação do Sistema Actividades Diversificadas Administrção de RH Administração. das TIC Concepção Implementação Manutenção Desenho Análise de Sistemas Desenvolvimento Exploração Planeamento A GSI é a gestão do recurso informação e de todos os recursos envolvidos no planeamento, desenvolvimento e exploração do SI. De modo a estebelecer os princípios e abordagens apropriados para o seu estudo e exercício, é fundamental compreender a natureza das suas actividades e envolventes. A complexidade das organizações está a aumentar, requerendo SI igualmente mais complexos para a satisfação das suas necessidades de informação. Há 10 anos, as principais preocupações da GSI consistiam no desenvolvimento de sistemas, na gestão de operações e nas relações com fornecedores. Agora há outras responsabilidades como a gestão de dados, a gestão de TI, a formação de RH, a consultoria, o planeamento, entre outros. No futuro provavelmente haverá ainda mais responsabilidades. Estas responsabilidades estão interligadas, é necessário a criação de uma visão global e integradora desta função. Conheceremos os aspectos envolvidos na gestão dos SI; planeamento, desenvolvimento e exploração

3 O processo de Desenvolvimento...
Recursos NTIC concepção construção SI utilizador RH implementação análise Um processo é um conjunto de actividades interligadas. O processo de desenvolvimento é tipicamente descrito em termos de um ciclo de vida integrado por um número de fases ou actividades chave. Todos os métodos de desenvolvimento actuais incluem 6 fases; concepção, análise, desenho, construção, implementação e manutenção. A ordem de execução destas actividades sim dependerá da abordagem ou método particular utilizado. Concepção: desenvolvimento do business case para o sistema de informação. Os clientes são o grupo de interesse de maior peso na determinação dos parâmetros para o business case. Em tal business case, os IS é avaliado estrategicamente em termos da contribuição ao rendimento organizacional. Uma avaliação da sua factibilidade também é feita em função das restrições e recursos organizacionais, e uma estimativa do grau de risco associado ao projecto. Análise: documentação do funcionamento de sistemas existentes e determinação dos requisitos do novo sistema. A análise envolve 2 actividade interligadas; extracção de requisitos e especificação de requisitos e deve envolver tanto pessoal de informática como representantes dos utilizadores Desenho: processo de planeamento da forma do sistema de informação novo e idealmente do sistema de actividade humano associado. Esta fase também devia envolver participação de representates dos utilizadores Construção: implica quer actividades de programação –subcontratadas ou com pessoal da casa-, quer a compra e configuração de pacotes. Implementação: envolve primeiramente, provas segundo as suas especificações, logo a instalação do sistema no seu contexto de uso. Manutenção: processo de feedback que envolve mudanças ao sistemas. Os sistemas de informação raramente permanecem na sua versão original. Os SI sofrem mudanças pelas seguintes razões: Erros na construção Mudanças na organização Erros na especificação de requisitos Mudanças tecnológicas Métodos, ferramentas desenho manutenção

4 Elaboração do “Business case” Estudo de factibilidade
Concepção do SI Planeamento do SI Análise do SI Elaboração do “Business case” Avaliação do risco Estudo de factibilidade A concepção constitui a primeira fase no processo de desenvolvimento.Nesta fase elabora-se o “business case” do SI. O “business case” é uma avaliação do SI em termos estratégicos. Também determina-se o grau de risco associado ao projecto. Finalmente, analisa-se a factibilidade do projecto em termos dos recursos organizacionais. O processo é ilustrado na figura.

5 Concepção do SI :: “Business Case”
Determinar o “valor” de negócio do SI Custos versus Benefícios SI são considerados investimentos de longo prazo o Business Case responde à pergunta: o investimento no SI produzirá suficientes retornos para justificar os seus custos? usando Capital Budgeting (ou outras técnicas) é o processo de analisar e seleccionar propostas de investimentos de capitais O desenvolvimento de um “business case” envolve a avaliação de um investimento de SI em termos do seu potencial para entregar benefícios contra os custos estimados. Isto é denominado como determinar o valor de negócio do SI. Os sistemas são considerados investimentos de longo prazo. O processo de analisar e seleccionar propostas de investimento de capitais é denominado por “capital budgeting”. Os modelos de “capital budgeting” são uma de várias técnicas para medir o valor do investimento em projectos de investimento de longo prazo. Existem 6 modelos de “capital budgeting” para avaliar projectos de investimentos de capitais: O método “payback”: mede o tempo requerido para pagar o investimento inicial do projecto: investimento original/rendimento neto anual O método do retorno do investimento (ROI): determinar uma taxa de retorno satisfatória depende do custo de pedir dinheiro emprestado além doutros factores, como as taxas de retorno históricas da empresa. Ao longo prazo, a taxa de retorno deve superar o custo do dinheiro no mercado. O cálculo da taxa de retorno implica ajustar os cash inflows segundo a depreciação: benefício neto = (benefícios totais – custos totais – depreciação)/vida útil O rádio custo-benefício: é muito simples benefícios totais/custos totais O valor presente neto: o valor de um projecto requer que o custo de um investimento seja comparado com o valor neto de rendimentos que acontecem anos depois. Estas verbas não são comparáveis devido a que o valor do dinheiro depende do tempo. Portanto, devemos calcular o valor presente desses rendimentos: valor presente= verba x (1 – (1 + 1juro) –n/juro = O “profitability index”: a limitante do valor presente neto é que não da medidas de profitability, nem permite ordenar várias propostas. Dividindo o valor presente entre o valor do investimento obtém-se um indice de profitability, os projectos podem ser ordenados segundo este indice. A taxa de retorno interno (IRR): variante do método do valor presente, toma em conta o valor temporal do dinheiro, Esta taxa iguala o valor presente dos fluxos futuros de caixa ao custo inicial do projecto i.e. Faz com que valor presente – custo inicial = 0.

6 Concepção do SI :: “Business Case”
existem 6 modelos de Capital Budgeting O método “payback” Mede o tempo requerido para pagar o investimento inicial do projecto Investimento original / rendimento líquido anual O método do retorno do investimento (ROI) A taxa de retorno deve superar o custo do dinheiro no mercado Benefício líquido = ( benefic totais – custos totais – depreciação ) / vida útil A relação custo-benefício Benefícios totais / custos totais O valor líquido presente o valor de um projecto requer que o custo de um investimento seja comparado com o valor líquido de rendimentos que acontecem anos depois valor presente= verba x (1 – (1 + 1juro) –n/juro O “profitability index” Dividindo o valor presente entre o valor do investimento obtém-se um indice de profitability (habilidade de lucrar) os projectos podem ser ordenados segundo este indice A relação de retorno interno (IRR) Variante do método do valor presente Valor presente – custo inicial = 0 O desenvolvimento de um “business case” envolve a avaliação de um investimento de SI em termos do seu potencial para entregar benefícios contra os custos estimados. Isto é denominado como determinar o valor de negócio do SI. Os sistemas são considerados investimentos de longo prazo. O processo de analisar e seleccionar propostas de investimento de capitais é denominado por “capital budgeting”. Os modelos de “capital budgeting” são uma de várias técnicas para medir o valor do investimento em projectos de investimento de longo prazo. Existem 6 modelos de “capital budgeting” para avaliar projectos de investimentos de capitais: O método “payback”: mede o tempo requerido para pagar o investimento inicial do projecto: investimento original/rendimento neto anual O método do retorno do investimento (ROI): determinar uma taxa de retorno satisfatória depende do custo de pedir dinheiro emprestado além doutros factores, como as taxas de retorno históricas da empresa. Ao longo prazo, a taxa de retorno deve superar o custo do dinheiro no mercado. O cálculo da taxa de retorno implica ajustar os cash inflows segundo a depreciação: benefício neto = (benefícios totais – custos totais – depreciação)/vida útil O rádio custo-benefício: é muito simples benefícios totais/custos totais O valor presente neto: o valor de um projecto requer que o custo de um investimento seja comparado com o valor neto de rendimentos que acontecem anos depois. Estas verbas não são comparáveis devido a que o valor do dinheiro depende do tempo. Portanto, devemos calcular o valor presente desses rendimentos: valor presente= verba x (1 – (1 + 1juro) –n/juro = O “profitability index”: a limitante do valor presente neto é que não da medidas de profitability, nem permite ordenar várias propostas. Dividindo o valor presente entre o valor do investimento obtém-se um indice de profitability, os projectos podem ser ordenados segundo este indice. A taxa de retorno interno (IRR): variante do método do valor presente, toma em conta o valor temporal do dinheiro, Esta taxa iguala o valor presente dos fluxos futuros de caixa ao custo inicial do projecto i.e. Faz com que valor presente – custo inicial = 0.

7 Concepção do SI :: Custos e Benefícios
Hardware Telecomunicações Software Serviços Pessoal Benefícios tangíveis Incremento na produtividade Custos operacionais menores Menor força laboral Gasto menor em computação Gasto menor em fornecedores Menos custos profissionais menr crescimento dos gastos Gasto menor em instalações Benefícios intangíveis: Melhor aproveitamento de activos Melhor controlo de recursos Melhor planeamento organizacional Maior flexibilidade organizacional Informação mais actualizada Mais informação Maior aprendizagem organizacional Cumprimento de requisitos legais Maior satisfação laboral Melhor tomada de decisões Optimização de operações Maior satisfação do cliente Melhor imagem corporativa No acetato aparecem os principais custos e benefícios de um SI. Na lista aprecia-se que os benefícios intangíveis são mais do que os tangíveis Benefícios tangíveis: Benefícios que podem ser quantificados e atribuídos a um valor monetário como a redução de custos operacionais Benefícios intangíveis: Não são facilmente quantificáveis como melhor serviços o melhor tomada de decisões.

8 Concepção do SI :: Limitações dos modelos financeiros
limita a responder à pergunta: o investimento no SI produzirá suficientes retornos para justificar os seus custos? Analisam somente os benefícios financeiros Contudo, os SI fornecem muitos benefícios intangíveis Os custos e os benefícios no final não decorrem simultaneamente os custos ocorrem no início e são tangíveis e os benefícios no final e são intangíveis a inflação pode afectar custos e benefícios diferentemente Embora alguns projectos de sistemas resultam em benefícios tangíveis directos como productividade e profitability, a maioria dos benefícios vão directamente ao consumidor na forma de preços mais baixos ou melhores serviços ou produtos. A sociedade recompensa as empresas que melhoram a mais valia ao cliente permitindo-as sobreviver o com ganhos maiores. Os competidores que falham no enriquecimento do consumidor, desaparecem. O valor dos sistemas desde um ponto de vista financeiro se limita a responder à pergunta de se o investimento no SI produzirá suficientes retornos para justificar os seus custos Existem muitos problemas com esta abordagem além de como estimar benefícios e contabilizar os custos Para começar os custos e os benefícios não ocorrem simultâneamente: os custos ocorrem no início e são tangíveis e os benefícios no final e são intangíveis. Portanto, a inflação pode afectar custos e benefícios diferentemente.

9 Concepção do SI :: Análise de risco
Actividades Identificação dos risco Gera um checklist de riscos associados a um projecto Estimação dos riscos probabilidade desse risco acontecer e do seu impacto Avaliação dos riscos ranking dos riscos planeamento de actividades para evitar ou monitorização estes riscos Factores de risco Tamanho do projecto Quanto maior o projecto, > o risco Experiência prévia Diminui os riscos Estrutura do projecto Não ocorrem objectivos contraditórios Devido a proliferação de fracassos em projectos de SI, a área de análise de risco tem-se convertido numa área prominente da engenharia de software e a literatura de desenvolvimento de sistemas. O risco pode ser definido como um resultado negativo que tem alguma probabilidade de acontecer em base a alguma experiência ou teoria. Um risco será salientado só se é relevante a um participante. Diferentes participantes verão diferentes riscos. Actividades envolvidas na análise de risco são: A identificação do risco: geração de um checklist de riscos associados a um projecto Estimação do risco: avaliação da probabilidade desse risco acontecer e do seu impacto. Avaliação do risco: ranking dos riscos e planeamento de actividades para evitar ou monitorização estes riscos A avaliação de riscos permite determinar o grau de risco de um projecto Existe uma serie de factores que incidem no grau de risco: o tamanho do projecto, experiência com a tecnologia, estruturação do projecto. A mais grande o projecto, maior o risco. Ter experiência prévia com a tecnologia a implementar diminui os riscos. Finalmente, os projectos enquanto mais estruturados, menor o risco. Um projecto estruturados não tem por exemplo, objectivos contraditórios, planos detalhados que facilitem a sua gestão, entre outros.

10 Concepção do SI :: Estudo de factibilidade
Devemos nos questionar: É possível o desenvolvimento do SI Com os recursos disponíveis e Com as restrições presentes? Um estudo de factibilidade é uma tentativa de determinar se um SI é factível com os recursos organizacionais disponíveis e perante as restricções presentes. O alcance inicial do SI deve ser comparado com a infraestrutura informática actual. Deve-se avaliar se o hardware, software, dados, capacidade de armazenamento e tecnologia de comunicações são suficientes para o sistema proposto. Também deve-se avaliar a organização requerida para o projecto e a hipótese de afectar os recursos solicitados. Idealmente o estudo de factibilidade deveria avaliar um leque de alternativas.

11 Concepção do SI :: outros modelos - Scoring Models
Critério peso As/400 Unix Windows XP % satisfação requisitos 0.4 2 0.8 3 1.2 4 1.6 Custo inicial 0.2 1 0.6 Financiamento 0.1 0.3 Facilidade de manutenção Hipótese de sucesso Total 1.9 3.2 4.0 Outros modelos: O portofolio análise considera a firma como possuidora de uma pasta potencial de aplicações. Cada aplicação tem riscos e benefícios. A pasta é descrita como tendo um perfil de riscos e benefícios. Embora não há um perfil ideial para todas as firmas, as industrias de informação por exemplo devem ter uns poucos projectos de alto risco e altos benefícios para manter o avanço da tecnologia, as empresas não baseadas em informação devem-se focar a projectos de baixo-risco e altos benefícios. Os riscos serão tolerados segundo a magnitude dos benefícios. O análise de pastas pode ser usado para seleccionar alternativas. Os projectos de alto risco e altos benefícios devem ser examinados cuidadosamente, os de baixo risco e grandes benefícios desenvolvidos, os de baixo risco e baixos benefícios reexaminados para aumentar os benefícios. Os de alto risco e baixos benefícios devem simplesmente, ser evitados O scoring models: com este modelo, cada alternativa é analisada segundo uma lista de critérios que tem cada um, um peso. Cada alternativa é avaliada com uma nota para cada critério. Os critérios surgem da discussão de especialistas. Este modelo envolve muitos juízos qualitativos.

12 Concepção do SI :: outros modelos - Portfolio Analysis
– pasta de aplicações (ou projectos) em potencial Benefícios Cuidado! desenvolver Evitar! Rotina Grau de risco Alto Baixo Outros modelos: O portofolio análise considera a firma como possuidora de uma pasta potencial de aplicações. Cada aplicação tem riscos e benefícios. A pasta é descrita como tendo um perfil de riscos e benefícios. Embora não há um perfil ideial para todas as firmas, as industrias de informação por exemplo devem ter uns poucos projectos de alto risco e altos benefícios para manter o avanço da tecnologia, as empresas não baseadas em informação devem-se focar a projectos de baixo-risco e altos benefícios. Os riscos serão tolerados segundo a magnitude dos benefícios. O análise de pastas pode ser usado para seleccionar alternativas. Os projectos de alto risco e altos benefícios devem ser examinados cuidadosamente, os de baixo risco e grandes benefícios desenvolvidos, os de baixo risco e baixos benefícios reexaminados para aumentar os benefícios. Os de alto risco e baixos benefícios devem simplesmente, ser evitados O scoring models: com este modelo, cada alternativa é analisada segundo uma lista de critérios que tem cada um, um peso. Cada alternativa é avaliada com uma nota para cada critério. Os critérios surgem da discussão de especialistas. Este modelo envolve muitos juízos qualitativos.

13 Próxima aula > análise, desenho, construção, implementação e manutenção
Recursos NTIC concepção construção SI utilizador RH implementação análise Um processo é um conjunto de actividades interligadas. O processo de desenvolvimento é tipicamente descrito em termos de um ciclo de vida integrado por um número de fases ou actividades chave. Todos os métodos de desenvolvimento actuais incluem 6 fases; concepção, análise, desenho, construção, implementação e manutenção. A ordem de execução destas actividades sim dependerá da abordagem ou método particular utilizado. Concepção: desenvolvimento do business case para o sistema de informação. Os clientes são o grupo de interesse de maior peso na determinação dos parâmetros para o business case. Em tal business case, os IS é avaliado estrategicamente em termos da contribuição ao rendimento organizacional. Uma avaliação da sua factibilidade também é feita em função das restrições e recursos organizacionais, e uma estimativa do grau de risco associado ao projecto. Análise: documentação do funcionamento de sistemas existentes e determinação dos requisitos do novo sistema. A análise envolve 2 actividade interligadas; extracção de requisitos e especificação de requisitos e deve envolver tanto pessoal de informática como representantes dos utilizadores Desenho: processo de planeamento da forma do sistema de informação novo e idealmente do sistema de actividade humano associado. Esta fase também devia envolver participação de representates dos utilizadores Construção: implica quer actividades de programação –subcontratadas ou com pessoal da casa-, quer a compra e configuração de pacotes. Implementação: envolve primeiramente, provas segundo as suas especificações, logo a instalação do sistema no seu contexto de uso. Manutenção: processo de feedback que envolve mudanças ao sistemas. Os sistemas de informação raramente permanecem na sua versão original. Os SI sofrem mudanças pelas seguintes razões: Erros na construção Mudanças na organização Erros na especificação de requisitos Mudanças tecnológicas Métodos, ferramentas desenho manutenção

14 Identificação de requisitos Especificação de requisitos
Análise do SI Concepção do SI Identificação de requisitos Análise do SAH A análise de sistemas é a análise do problema que a organização tentará resolver com um SI. Implica definir os problemas, identificar as suas causas e identificar uma solução e os requisitos de informação que devem ser satisfeitos pela solução de sistemas. Nesta se descreve a situação desejada sem incluir aspectos técnicos. Um dos maiores desafios do analista de sistemas é a definição dos requisitos de informação específicos que uma solução deve satisfazer. A definição de requisitos envolve 2 actividades fortemente interligadas; a identificação de requisitos e a especificação de requisitos. A especificação de requisitos requer de técnicas para os representar. Nesta fase é também importante analisar o contexto de actividade humana que rodeia o sistema de informação tecnológico. Isto envolve actividades como análise de tarefas e análise do trabalho (job analysis) Especificação de requisitos Desenho do SI

15 Análise do SI :: Identificação de requisitos
Identificação de actores (stakeholders) Donos ou clientes Administradores Utilizadores finais Requisitos: características e funcionalidades requeridas do SI Variam segundo o tipo de utilizador Podem ser contraditórios Devem ser guardados. São a base na construção do sistema Contudo, variam com o tempo a identificação envolve Determinar quem precisa qual informação, onde e como Uma das primeiras coisas a fazer é a identificação dos actores envolvidos i.e. Donos ou clientes, administradores e utilizadores da informação. Estes actores são denominados em inglês como “stakeholders”. Donos ou clientes: são tipicamente os grupos de gestão dentro da organização, que estabelecem os objectivos chave do SI em termos da sua utilidade i.e. Em termos do seu suporte à organização. Utiilzadores finais: estabelecem os requisitos de funcionalidade e usabilidade (segurança, performance,tipo de interface). A identificação de requisitos envolve determinar quem precisa qual informação, onde, quando e cómo. A análise de requisitos define cuidadosamente os objectivos do sistema e desenvolve uma descrição detalhada das funções que o novo sistema deve realizar. Um requisito é qualquer características ou funcionalidade desejada do sistema. Os requisitos não são fenómenos objectivos, dependem do ponto de vista dos diversos participantes e grupos de interesse do sistema. De facto, os requisitos podem ser contraditórios exigindo ao analista a obtenção de consensos inter-subjectivos entre os diversos participantes. Por forma a construir um sistema de informação (um artefacto), os requisitos devem ser congelados, mas é um facto de que são variáveis no tempo.

16 Análise do SI Exemplo: Sistema de gestão da investigação na universidade (requisitos funcionais)
Gestão da informação sobre os artigos (papers) de investigação produzidos na universidade Gestão de informação sobre o pessoal de investigação da universidade Monitorização da actividade investigação e da sua performance Geração de informação de investigação para agentes externos Gestão das actividade de orientação da investigação de estudantes

17 Análise do SI Exemplo: Sistema de gestão da investigação na universidade (requisitos funcionais)
Prazo de construção do sistema: 6 meses Para ser usado por coordenadores ou administradores de investigação e investigadores dos departamentos Um programador e um analista disponíveis para o projecto Um computador disponível para o desenvolvimento

18 Análise do SI :: Levantamento de requisitos
Entrevistas Observação Análise documental Workshops Protótipos Etnografia técnicas que envolvem a observação e uma estreita ligação com os participantes apreciação aprofundada dos processos explícitos e tácitos do trabalho O levantamento de requisito é o processo dedicado a identificação de requisitos. Este processo tem sido chamado como captura de requisitos mas isto não é exacto porquanto os requisitos são subjectivos que envolvem processos de negociação entre os interessados. Para o levantamento de requisitos existem uma série de técnicas: Entrevistas- é a técnica mais comum. São discussões formais ou informais com representantes de cada um dos grupos de interesse. As entrevistas formais são conversas estruturadas nas quais as perguntas são determinadas com antecipação. As entrevistas informais são discussões onde as perguntas são colocadas segundo o fluxo da própria entrevista Observação: Frequentemente o que as pessoas descrevem nas entrevistas reflecte parcialmente a realidade. Portanto, estas devem ser complementadas com a observação e registo do comportamento das pessoas no desenvolvimento do seu trabalho. Análise documental: são muito importantes para indicar os dados requeridos por um sistema de informação e a classe de reportes que devem ser gerados. Workshops: constituem sessões nas quais analistas e representantes dos utilizadores se juntam num situação estruturada por forma a formular requisitos para o sistema. São ambientes controlados para a negociação de requisitos. Protótipos: Muitas vezes os utilizadores não conseguem exprimir os seus requisitos sem verem alguma respresentação de alguma inovação proposta São demos que mostram o potencial do sistema Etnografia: são um conjunto de técnicas que envolvem a observação e uma estreita ligação com os participantes por forma a ganhar uma apreciação aprofundada dos processos explícitos e tácitos do trabalho Tem sido utilizada para obter representação detalhadas de situações como precursor ao desenho do sistema.

19 Análise do SI :: Especificação de requisitos
levantamentos transferências depósitos administração cliente operador Sistema Do banco Tem a ver com a representação dos requisitos estabelecidos no levantamento. Requer dalguma notação intermédia de fácil compreensão para os utilizadores. Esta notação é frequentemente gráfica. O exemplo mais relevante são os use cases do UML. Os use cases são uma técnica centrada no utilizador que descreve as interacções de alto nível entre os diversos utilizadores e o sistema. Usa 2 entidades, actores e use cases. Um actor é qualquer pessoa, máquina ou sistema de informação que interage com o sistema. Os diagramas de clase do UML, diagramas de colaboração e sequência também são utilizados na fase de análise. > UML: casos de utilização, diagramas de classe, sequencia, etc.

20 Análise do SI :: Técnicas para a Análise do SAH
Task Analysis: decomposição do trabalho numa hierarquia de processos, actividades e tarefas. Workflow: uma variante da anterior, só que + complexo pois associa pessoas, documentos, programas, etc. Job Analysis: analise do trabalho em termos dos objectivos da organização versus os objectivos do individuo Eficiência organizacional: Especialização do trabalho Segmentação do trabalho Satisfação laboral do indivíduo exercitar suas habilidades perceber seu valor na organização possuir alto grau de autonomia permitir relações sociais mesclar rotina com novas exigências não interferir na vida pessoal Task analysis: Implica a decomposição do trabalho numa hierarquia de processos, actividades e tarefas. Uma variante é o denominado Workflow. No workflow se associam pessoas, documentos e programas as diversas actividades. È muito similar ao desenho de processos mas trabalha a um maior nível de detalhe. Job analysis: envolve a análise do conteudo e relações do trabalho em termos dos objectivos organizacionais e individuais. O incremento da especialização e a segmentação de tarefas favorece os objectivos da organização. No entanto, entram em conflito com os objectivos individuais porquanto prejudicam a motivação e a flexibilidade. Em termos gerais os trabalhos mais satisfatórios dão oportunidade para exercitar as habilidades e aprender outras, percebe-se qual o seu significado e valor para a organização, dão um alto grau de autonomia, implicam colaboração e comunicação com outros, misturam a rotina com novas exigências que o trabalhador tem poder para aceitar ou rejeitar. Finalmente, o trabalho não deve interferir demasiado com a sua vida pessoal e familiar. Atingir um compromisso entre os objectivos organizacionais e individuais implicam trabalhos que dão algum grau de especialização e de autonomia. Entre as estratégias para conseguir isto econtram-se: a rotação no trabalho, a combinação de um maior conjunto de tarefas e a atribuição de um maior poder de decisão. O trabalho em equipa é também fonte de satisfação laboral. Estratégia ao bom senso Rotação no trabalho Alargamento do trabalho > conjunto de tarefas Enriquecimento do trabalho > poder de decisão

21 Desenho do SI Planos do artefacto técnico que satisfaz os requisitos estabelecidos na fase de análise Mostra como se vai implementar a solução descrita Desenho Lógico Desenho de entradas, saídas, processos, dados, comunicação, qualidade e segurança Desenho Físico Desenho do Hardware, Software, Bases de Dados, Interfaces, HW e SW das Comunicações usa diagramas UML específicos para esta fase Diagramas de Componentes Actualizam-se Diagramas de Caso de Utilização (use-cases), de Classes, Sequência, etc. Em termos gerais o desenho pode ser dividido em desenho lógico e desenho físico. O desenho lógico envolve as seguintes actividades: Desenho de entradas Desenho de saídas Desenho dos processos Desenho dos dados Desenho das comunicações Desenho dos controlos (qualidade) e segurança A nível físico o desenho envolve: Desenho do Hardware Desenho do Software Desenho do hardware e software das comunicações, Desenho das bases de dados Desenho das interfaces

22 Desenho do SI :: o desenho do SAH abrange
Desenho do trabalho (Job design) para balancear a satisfação laboral com a eficiência no trabalho Desenho de equipas (Team design) para estabelecer equipas como claras estruturas de autoridade e controlo Desenho dos procedimentos de trabalho (Procedure design) para detalhar os novos padrões de trabalho Os SAH como já sabemos conjuntos de pessoas e actividades ou procedimentos. Portanto, a nível do desenho, há três actividades envolvidas: Desenho do trabalho para balancear a satisfação laboral com a eficiência no trabalho Desenho de equipas para estabelecer equipas como claras estruturas de autoridade e controlo Desenho de processos para detalhar os novos padrões de trabalho Na maioria das organizações comerciais, os grupos de gestão tipicamente determinam a forma dos SAH. McGregor (1960) identificou 2 conjuntos de teorias que influenciam a forma em que os gestores pensam em relação aos seus trabalhadores. Estas teorias, chamadas X e Y dizem: Teoria X: as pessoas típicas não gostam do trabalho e o evitam quando possível. O indivíduo médio evita as responsabilidades e tem pouca ambição Teoria Y: Segundo esta teoria, os esforço físico e mental são funções importantes e naturais no ser humano. Se os indivíduos estão comprometidos com objectivos determinados, exercerão auto-control e auto-direcção Os SAH desenhados dependerão da aplicação de uma de estas teorias. Se a teoria aplicada for a X serão desenhados com a intenção de monitorizar a força de trabalho e controlar o seu comportamento através da coerção. Os objectivos dos IS serão fornecer a informação requerida para exercer este tipo de controlo. Se a teoria aplicada for a Y, os HAS estarão desenhados para promover a criatividade. Os SI terão o objectivo de encorajar a cooperação e colaboração entre os elementos da força de trabalho

23 Construção do SI Programação Testes
as especificações do sistema que foram preparadas na fase de desenho são traduzidas a código Testes Unit – programas ou componentes em separado System – testa o sistema completo Volume – testa a escalabilidade dos grandes volumes de dados Acceptance – avaliação por utilizadores e gestores Durante a programação, as especificações do sistema que foram preparadas na fase de desenho são traduzidas a código. As organizações podem desenvolver o seu próprio código, comprar pacotes externos ou contratar ou serviço de desenvolvimento. Testes: para ter a certeza de que o sistema funciona bem, tem de se conduzir muitos testes. De facto, os erros nos programas complexos nunca são completamente eliminados. Os testes podem ser de quatro tipos: unit (programas ou componentes por separado), sistema (testes do sistema completo), volume (testes com grandes volumes de dados) e acceptance (avaliação por utilizadores e gestores).

24 Construção do SI :: Conversão do sistema antigo ao novo
4 estratégias para a Conversão Paralela – mantém os 2 funcionando até garantir que o novo funciona correctamente embora segura, é a técnica + cara Directa – o novo funcionará numa data determinada é + simples e + barata, porém arriscada Piloto – introduz o sistema numa área limitada quando o piloto funcionar bem, instala o sistema todo Faseada – introduz o sistema gradualmente quer por funcionalidades, quer por unidades organizacionais A conversão é o processo de passar do sistema antigo ao novo. Existem 4 estratégias de conversão: paralelo que implica manter o funcionamento do sistema novo e antigo simultaneamente até garantir que o novo funciona correctamente. Esta estratégia embora segura, é cara. A conversão directamente implica por a funcionar o sistema novo a partir de uma data pre-determinada. É mais simples e barato mas arriscada. O piloto introduz o sistema numa área limitada, quando o piloto funcionar bem então é o sistema é instalado no resto da organização. A estratégia faseada introduz o sistema gradualmente quer por funcionalidades quer por unidades organizacionais

25 Construção do SI :: Alternativas de construção de sistemas
Desenvolvimento in-house Modelos em cascata Sequencial (Ciclo de vida clássico) Revisto Construção de Protótipos Desenvolvimento Rápido de Aplicações Modelos Evolutivos Incrementais Iterativos Iterativos e Incrementais Espiral Modelos de Processos OO Modelo Recursivo/Paralelo Outos.. O ciclo de vida clássico é o método mais antigo de construção de sistemas. Implica a existência de várias fases concepção, análise, desenho, construção...Cada fase deve ser completada antes de passar a outra. Implica uma grande divisão do trabalho entre analistas e programadores.Além disso é muito inflexível e presume e implica pouca comunicação entre utilizadores e informáticos uma vez acabada a fase de análise. Protótipos: implica construir rapidamente e com pouco custo sistemas experimentais que serão refinados iterativamente até satisfazer de forma precisa, os requisitos dos utilizadores. O processo é iterativo porque envolve passar por todas as fases de desenvolvimento várias vezes. O risco principal desta abordagem reside em confundir um protótipo com o produto final. O processo de desenvolvimento pode ser muito comprido se houver muitos utilizadores envolvidos.

26 Modelo Processo OO Baseado em componentes
Identificar classes candidatas recursivo (modelo evolutivo) paralelo (reutilização de componentes) buscar classes na biblioteca extrair classes, se existem desenvolver novas classes, se não existem adicionar novas classes à biblioteca construir n-ésima iteração do sistema Análise de Riscos Engenharia e Construção Variante do modelo iterativo e incremental. Proposto por B. Boehm como resposta as críticas sobre a falta dos outros processos evolutivos na utilização de prototipos e reutilização de software. Permite a construção rápida de aplicações em versões incrementais. Durante as primeiras iterações, a versão incremental poderia ser um modelo em papel o um prototipo. Durante as últimas iterações, se produzem versões cada vez mais acabadas. O modelo em espiral se divide num número de actividades de enquadramento do trabalho, denominadas por regiões de tarefas. Geralmente, existem entre 3 e seis regiões. A figura representa um modelo em espiral que contem 6 regiões: Comunicação com o cliente: estabelecimento de comunicação entre o responsável pelo desenvolvimento e o cliente Planeamento: definição de recursos, tempo e outras informações relacionadas Análise de riscos: avaliação de riscos técnicos e de gestão Engenharia: construção de uma ou mais representações da aplicação Construção e acção: construção, teste, instalação e suporte ao utilizador (treino, documentação e prática) Avaliação do cliente: avaliação da reacção do cliente das representações do software criadas na etapa da engenharia e implementada na etapa de construção e acção Cada das regiões estão compostas por um conjunto de tarefas que se adaptam as características do projecto. Para projectos pequenos o número e formalidade das tarefas é baixo. Em projectos maiores, cada região terá uma série de tarefas definidas para atingir um nível mais alto de formalidade. Em todos os casos se realizam actividades de gestão da configuração e controlo da qualidade Baseado em componentes Unified Development Process Derivado da orientação a objectos Utiliza UML

27 Construção do SI :: Alternativas de construção de sistemas
Comprar pacotes de software Existem aplicações comuns a muitas organizações Contratar terceiros (Outsourcing) para construção ou operação de SI pode ser + vantajoso que manter um centro de desenvolvimento mantém controlo sobre as tendências tecnológicas Pacotes de software: existem aplicações comuns a muitas organizações. A compra de pacotes pode poupar muito dinheiro e tempo. Tipicamente, estes pacotes podem ser personalizados para satisfazer a maioria dos requisitos da empresa.E preferível comprar um pacote que satisfaz um 70% dos requisitos da empresa antes de fazer um desenvolvimento inhouse. Outsourcing: prática de contratar as operações de um centro de computação quer para construir os seus sistemas, que para opera-los. Algumas empresas tem encontrado no outsourcing uma solução porque resulta mais eficaz que manter o seu próprio centro de computação ou pessoal de informática. O fornecedor do serviço se beneficia com economias de escala (as mismas capacidades para vários clientes). Para empresas com necessidades fluctuantes em termos de processamento de informação pode resultar apropriado. Outra razão pode ser a incapacidade da empresa para manter treinado o seu pessoal nas últimas tecnologias o práticas de negócio inovadoras. Mas o outsourcing também tem disvantagens, a empresa pode perder o controlo dos seus Sistemas de Informação. Se o contrato não for bom também se pode perder o controlo sobre as tendências tecnológicos. Deve prestar-se atenção as contratações de desenvolvimento de sistemas de informação estratégicos.

28 Implementação do SI :: devemos verificar 2 aspectos principais
Aspectos técnicos Adquisição de Hardware Software Preparação dos dados e conversão Instalação de Introdução dos dados Testes da instalação Introdução a produção Aspectos sociais Formação dos grupos de utilizadores Treinamento de utilizadores e operadores Aceitação dos utilizadores

29 Manutenção do SI :: o que é? o porquê? Tipos.. Gestão
é o trabalho desenvolvido para corrigir ou melhorar os sistemas após a sua implementação O Porquê? Erros no sistema (bugs) Erros nos requisitos Mudanças nos processos Mudanças nos requisitos Problemas técnicos com hardware/software Mudanças no ambiente A manutenção é o trabalho desenvolvido para corrigir ou melhorar os sistemas após a sua implementação e geralmente envolve recursos significativos . Qualquer sistema, independentemente da qualidade do seu desenvolvimento, deverá ser continuamente modificado, de modo a suportar a mudança dos requisitos funcionais. Apesar de frequentemente ser considerada uma componente de menor importância, a manutençãop dos sistemas existentes ocupa cerca de 70% do esforço do DSI. A sua complxidade dependerá em grande medida do rigor de realização de todas as actividades do DSI.

30 Manutenção do SI :: Tipos de manutenção
Aperfeiçoamento mudanças que são feitas ao sistema para introduzir melhorias mas sem afectar a funcionalidade do sistema Adaptação mudanças feitas para fornecer um melhor alinhamento do sistemas com o seu SAH Correcção mudanças feitas para corrigir erros quer a nível do software, quer a nível dos requisitos Prevenção previsão a mudanças futuras Segundo as suas causas, a manutenção pode ser classificada em 4 tipos principais: Manutenção de aperfeiçõamento: mudanças que são feitas ao sistema para introduzir melhorias mas sem afectar a funcionalidade do sistema Manutenção adaptativa: mudanças feitas para fornecer um melhor alinhamento do sistemas e o seu SAH Manutenção correctiva: mudanças feitas para corrigir erros quer a nível do software, quer a nível dos requisitos Manutenção preventiva: mudanças para melhorar a própria manutenção do sistemas ou a sua flexibilidade i.e. Em previsão a mudanças futuras.

31 Manutenção do SI :: Como gerir o “processo” de manutenção
Manutenção do SI :: Como gerir o “processo” de manutenção? - devemos considerar 4 aspectos Equipas de manutenção responsáveis pela modificação, correcção e actualização dos sistemas tecnológicos Análise de flexibilidade os SI podem ser desenhados tomando em conta a manutenção futura Gestão da configuração controlo das versões dos produtos de desenvolvimento de software Versão 3.11 (para ser usado em rede) ou 3.1 (para uso individual) aplicada ao longo de todo o processo de desenvolvimento Renovação de sistemas legados migração dos SI actuais para novos ambientes de hardware, software e comunicações Coma já vimos, a manutenção é uma actividade intensa na maioria das organizações, portanto é uma actividade que deve ser gerida como um processo. Algumas estratégias para o fazer são: Equipas de manutenção: formação de equipas de manutenção especializadas e responsáveis pela modificação, correcção e actualização dos sistemas tecnológicos. Políticas de prémios podem ser criadas para recompensar o bom desempenho desta actividade Análise de flexibilidade: Os sistemas podem ser desenhados tomando em conta a manutenção futura. Neste sentido a flexibilidade será um critério fulcral em prevenção de mudanças futuras Gestão da configuração: Tem a ver com o controlo das versões dos produtos de desenvolvimento de software. Uma efectiva gestão da configuração é indispensável para uma boa manutenção. Cada configuração de IT numa organização deve ser documentada no máximo possível. A gestão da configuração é uma actividade de suporte que é aplicada ao longo de tudo o processo de desenvolvimento. É uma actividade chave no serviço de informática e envolve as seguintes actividades: Identificação de mudanças nos produtos do desenvolvimento de software Controlo das mudanças feitas aos produtos Assegurar que as mudanças sejam feitas apropriadamente Informar das mudanças aos outros A gestão da configuração overlaps com a manutenção de sistemas mas existe ao longo do processo de desenvolvimento completo e constitui um elemento importante para assegurar a qualidade dos sistemas Renovação de sistemas legados: o planeamento da modernização dos sisemas legados para novos ambientes de hardware, software e comunicações deve ser uma parte essencial de qualquer estratégia de informática