Nesta mensagem e em suas respostas procurarei demonstrar a minha visão sobre a
evolução da Análise de Sistemas.
Recuperei dois textos produzidos em
1999:
=== Construção e manutenção de sistemas
=== DesSistema
(Metodologia básica de minha empresa, CEPRO, empregada nos projetos da época)
Do primeiro texto segue o diagrama síntese do processo de construção e
manutenção de sistemas:
Problema : Construir o sistema com qualidade e
manter operando, sem perda de qualidade, enquanto adequamos o sistema a novas
necessidades.
(A) Histórico :
(A1) [Dados e lógica]
construído para cada solução (1950 – 1980)
(Criação de programas e não
de sistemas)
Ex.:
=== Código “spaghetti” e arquivos por programa.
=== Planilhas -> Dados, fórmulas e resultados “embaralhados”.
(Evolução = Áreas definidas de entrada de dados, fórmulas e apresentação de
resultados.)
Projeto : Fluxogramas / Folhas de definição de campos de
arquivos.
Construir e manter programas como arte.
(A2)
Sistemas Gerenciadores de Bancos de Dados e módulos de lógicas
(1980-1995)
Análise/Projeto estruturado (DFD, DER, DD,
micro-especificações).
Programação estruturada ( 5 estruturas, GOTO
proibido).
Tabelas de referências cruzadas (Aplicações e funções usadas,
aplicações/funções e colunas de tabelas).
Fluxo de controle de
sistemas/programas.
TblParametros.nroVersão e NroVersão em cada
aplicação.
Modularidade (Djkastra).
Outras fontes : Yourdon,
Page-Jones, Gane & Sarson
Grande melhora no processo de construção,
mas dificuldade no processo de manutenção para quem não usa ferramentas CASE.
(A3) Orientação a objetos
Análise/projeto/programação
como um contínuo detalhamento dos objetos.
Analogia : indústria automobilística, um sistema é uma montagem de componentes disponíveis e
utilizáveis em vários sistemas.
Modularidade radical –> objeto =
(dados/propriedades+eventos+métodos).
Projeto : Diagrama de Transição de
Estados.
Construção por composição de objetos já testados com novos,
manutenção facilitada por característica de encapsulamento (aperfeiçoamento de
funções de objetos ficam disponíveis para todos os sistemas que os utilizem,
novas funções para objetos não impactam sistemas já implantados.
Restam
algumas dificuldades de implantação (ambiente cliente-servidor) :
======
Parte do objeto no servidor (ex.: dados, triggers, stored procedures).
====== Parte do objeto na estação (ex.: interface com usuário).
======
Garantia de compatibilidade entre estas partes.
====== Compor ou não um .exe
para o sistema (agrupando os objetos) ?
(B) Usar convenção de
nomenclatura da Microsoft.
(C) Classes e objetos.
Classe Faturas (Faturas de clientes)
====== Faturas de clientes “A”
(Obj)
====== Faturas de clientes “B” (Obj)
====== Faturas de clientes
“C” (Obj)
Metodologia de desenvolvimento de sistemas
.................................................... CEPRO
....................................................
Consultoria em sistemas de informação
.................................................... para excelência e
produtividade.
Elaborado por :
Claudio Estevam Próspero
28/06/1999
Fases do desenvolvimento de um sistema de
informações
1. Arquitetura ( O QUE ? POR QUE ? )
2.
Projeto ( COMO ? QUANDO ? QUANTO ? QUEM ?)
3. Construção ( Programação e
Testes )
4. Implantação ( Uso do Sistema)
As fases (1) e
(2) consomem, normalmente, de 10% a 15% do tempo de criação de um sistema, mas a
sua correta execução permite a otimização da fase (3) e, no limite, evita um
ótimo sistema, como técnica de construção, que não atende as necessidades para
as quais foi, ou deveria ter sido, construído.
Uma ótima analogia é a
construção de um prédio, impossível de chegar a bom termo sem um bom projeto, e
um desastre de vendas se não houver uma boa arquitetura.
É na fase de
arquitetura que se cria a motivação para iniciar o sistema e, principalmente,
para persistir na sua construção e implantação, na dura passagem da "perfeição
dos sonhos", para o "sofrimento com as limitações da realidade". Se os "POR QUE
?" dos "O QUE ?" se idealizou forem realmente bons, todos persistirão na sua
construção. (Dependendo dos benefícios, aceita-se os custos).
A
arquitetura de um sistema deve ser a "utopia". No projeto se "põe os pés no
chão" em função das limitações (tecnológicas, organizacionais,etc.), mantendo-se
a "utopia" como referência para aplicação de novas tecnologias, evoluções
organizacionais, etc. ,que permitam aproximações de novas versões do sistema, do
que foi idealizado.
Sugestões de Ferramentas para Cada Fase
1.
Arquitetura
Matriz de pontos levantados (problemas ou sugestões dos
entrevistados para o sistema) contendo as seguintes informações :
===
Nro. Ponto
=== Descrição do Ponto (problema ou sugestão)
===
Areas/Setores Afetados
=== Problemas Potenciais (da persistência do
problema ou da não implantação da sugestão)
=== Ações Sugeridas ( para
solucionar o problema ou para implantar a sugestão)
=== Referência aos
Projetos que Contribuem para as Ações Sugeridas
====== Projetos
Funcionais ou Organizacionais (alterações ou implantação de
políticas/procedimentos).
====== Projetos de Sistemas de Informações
(alteração ou implantação de sistemas computacionais).
====== Rede de
Interdependência entre os Projetos (quais os pré-requisitos de cada projeto).
2. Projeto (para cada projeto de sistema listado acima)
Diagrama de Entidades/Relações + Dicionário de Informações (quais, sem
preocupação com suas características fisicas. Em um levantamento da situação
atual podem ser utilizadas cópias preenchidas dos documentos
atuais/telas/relatórios).
Diagrama de Fluxo de Dados + Descrições de
Processos.
Diagrama de Controle de Programa (Inicio + Tratamento + Fim)
ou Diagrama Hierárquico de Funções (Batch ou processos sequenciais).
Diagrama de Transição de Estados ou Diagrama de Eventos (processos
orientados à eventos).
Protótipos - em ambientes de desenvolvimento tipo
Access pode ser obtido um protótipo sem código, e utilizando-se uma ferramenta
de documentação (Ex. TotalAnalyzer), obter-se alguns dos diagramas acima.
Arvores de Decisões.
Fluxogramas.
3.
Construção
Linguagens ou Geradores de Soluções conforme as
especificações de cada projeto (Access, VisualBasic, Cobol, SQL, Excel, etc.).
Análise de sistemas - Comentários
Porque usar
diagramas.
Para organizar e tornar facilmente acessível grandes
quantidades de informações sobre um dado assunto de interesse. Um padrão de
diagramação comum a um grupo, permite a partilha do conhecimento organizado
entre os membros do grupo.
Diagramas como modelos de sistemas.
Construindo modelos de sistemas através de diagramas e/ou protótipos
conseguimos testar a funcionalidade e apresentação do sistema antes de grandes
investimentos em programação. O ideal utópico de uma modelagem é a construção de
um sistema que atenda todos os requisitos de funcionalidade e apresentação já na
sua primeira versão.
Diagramas como input para planejamento.
Assim como o grau de conhecimento contido em um mapa rodoviário, dado
pelo nível de detalhe representado em sua convenção de simbologia, permite o
melhor planejamento de uma viagem, o grau de conhecimento capturado sobre um
sistema em diagrama(s), permite maior precisão no planejamento dos recursos
necessários à sua construção.
Etapas de um projeto, uma
analogia.
Ver na mensagem inicial desta sequência (Análise de
Sistemas - Evolução - Estruturada / Objeto / SOA)
Padrões de
diagramação comuns em análise de sistemas.
Projeto
lógico(levantamento): mapa de entidades-relacionamentos, dicionário de
dados, diagrama de fluxo de dados, descrição de processos, fluxogramas, tabelas
de decisões.
Projeto físico : diagramas de input / output,
diagramas de estrutura de programas (modularidade, operações da programação
estruturada (sequência, loop, if, case)), pseudo-código, tabelas de decisão,
fluxograma, books(Cobol) ou geradores de tabelas(Sql, xBase, Access).
Porque usar análise orientada a objetos.
Para
diagramar sistemas onde existe paralelismo de processamento e expandir o
conceito de modularidade das funções para os objetos(dados e funções como um
"pacote"), permitindo a construção de sistemas complexos como montagem de
objetos disponíveis, dos quais só conheçamos o comportamento, sem preocupação
com sua complexidade interna.
Conceitos de diagramação como
ferramentas.
Considere os conceitos de diagramação e metodologias de
desenvolvimento como sua caixa de ferramentas de trabalho, tenha uma grande
quantidade, de boa qualidade, e saiba como e, principalmente, quando usar cada
uma.
Diagrama de fluxo de dados (funções do sistema).
Diagrama de fluxo de dados representando a aplicação da metodologia aqui
sugerida.
Notação :
D(9) - representa um depósito de
dados (conjunto de documentos ou base de dados em computador)
E(9) -
representa algo fora do escopo do sistema em análise, mas que interage com este
sistema.
F(9) - representa um fluxo de dados de entrada ou saída de um
processo.
P(9) - representa um processo de tratamento de dados (manual
ou automático).
Diagrama de entidades e relacionamentos (relações entre os dados).
Desenvolvimento de sistemas
Depósitos de dados
D1 - Matriz resumo do estudo
Número do ponto
Descrição do ponto
===Problema ou sugestão levantado em entrevistas
ou percebido pela equipe durante estudo.
Areas/setores afetados
===Define usuários e interfaces potenciais do sistema em análise.
Problemas potenciais
===Danos que podem vir a ocorrer, ou ganhos não
obtidos, se o ponto não for tratado pelo sistema ( aqui temos os benefícios que
justificam os custos das ações recomendadas).
Ações sugeridas
===Para solucionar o problema ou para implantar a sugestão.
Projetos
relacionados ao ponto
===Identificação dos projetos (organizacionais ou de
sistemas de informações) que contribuem para uma ou mais das ações sugeridas.
====== Projetos Organizacionais - alterações ou implantação de
políticas/procedimentos.
====== Projetos de Sistemas de Informações -
alteração ou implantação de sistemas computacionais.
D2 - Projetos
Identificados
Identificação do projeto
Objetivo do projeto
D3 - Fluxo de projetos (ou sua relação de interdependência)
Identificação do projeto fim
===Projeto que se pretende desenvolver.
Identificação do projeto prévio
===Projeto(s) que devem estar
desenvolvidos para que se possa atuar no projeto fim (pré-requisitos).
D4 - Projetos Organizacionais
Objetivo
Histórico
=== O "POR QUE ?" do projeto, com descrições de ocorrências que levaram a
percepção de sua necessidade.
Descrição sumária
=== Idéias surgidas
na equipe de estudo e que podem orientar o detalhamento do projeto.
Documentos de detalhamento
=== Identificações de documentos ou
arquivos de computador onde está detalhado o projeto
(Ex. : Diagramas de
Fluxos de Dados, Diagramas de Pareto, Diagramas de Causa e Efeito, Atas de
Reuniões, etc.)
D5 - Projetos de Sistemas de Informações
Objetivo
Histórico
=== O "POR QUE ?" do projeto, com
descrições de ocorrências que levaram a percepção de sua necessidade.
Descrição sumária
=== Idéias surgidas na equipe de estudo e que
podem orientar o detalhamento do projeto.
Documentos de detalhamento
===Identificações de documentos ou arquivos de computador onde está
detalhado o projeto
(Ex. : Diagramas de Fluxos de Dados, Diagramas de
Entidades-Relacionamentos, Diagramas de Controle de Programas (rotinas de
processamento sequencial), Diagramas de Transição de Estados ou Diagramas de
Eventos (aplicativos orientados à eventos ou orientados à objetos), Árvores de
Decisões, Fluxogramas, etc..))
Desenvolvimento de sistemas
Fluxos de dados
F1 - Solicitação de Análise
Documento descritivo contendo as informações relevantes sobre o problema que deve ser analisado. Abaixo algumas sugestões de tópicos :
1. Visão e escopo.
A visão é a definição, em nível macro, do "O QUE ?" se pretende com o novo sistema, ou nova versão de sistema já existente.
O escopo é a abrangência, em termos de setores da empresa, ou assuntos, que o estudo deve contemplar.
2. Histórico.
Aqui procura-se o "POR QUE ?" da solicitação do sistema, com descrições de ocorrências que levaram a percepção de sua necessidade.
3. Objetivos.
É o detalhamento da visão ("O QUE ?" ), em termos mensuráveis. Aqui define-se os fatores críticos de sucesso do sistema (o que ele precisa atender para que sua implantação seja viável).
4. Restrições e exceções.
As restrições definem o que o estudo não pode propor mudar.
Nas exceções lista-se o que já se percebeu que não tem regras, e portanto não é passível de ser tratado no sistema, e o que se fará quando estas situações ocorrerem.
F2 - Novo Processo de Trabalho
Conjunto de documentos e sistemas que serão a base do novo método de trabalho dos setores afetados pelo sistema em implantação.Alguns exemplos :
1. Politicas e normas que devem ser respeitadas para que novo processo funcione.
2. Kits de instalação do novo sistema/versão, com suas instruções de uso.
3. Manuais de utilização do novo sistema/versão.
4. Material base de treinamento dos usuários.
Fluxos de dados
F1 - Solicitação de Análise
Documento descritivo contendo as informações relevantes sobre o problema que deve ser analisado. Abaixo algumas sugestões de tópicos :
1. Visão e escopo.
A visão é a definição, em nível macro, do "O QUE ?" se pretende com o novo sistema, ou nova versão de sistema já existente.
O escopo é a abrangência, em termos de setores da empresa, ou assuntos, que o estudo deve contemplar.
2. Histórico.
Aqui procura-se o "POR QUE ?" da solicitação do sistema, com descrições de ocorrências que levaram a percepção de sua necessidade.
3. Objetivos.
É o detalhamento da visão ("O QUE ?" ), em termos mensuráveis. Aqui define-se os fatores críticos de sucesso do sistema (o que ele precisa atender para que sua implantação seja viável).
4. Restrições e exceções.
As restrições definem o que o estudo não pode propor mudar.
Nas exceções lista-se o que já se percebeu que não tem regras, e portanto não é passível de ser tratado no sistema, e o que se fará quando estas situações ocorrerem.
F2 - Novo Processo de Trabalho
Conjunto de documentos e sistemas que serão a base do novo método de trabalho dos setores afetados pelo sistema em implantação.Alguns exemplos :
1. Politicas e normas que devem ser respeitadas para que novo processo funcione.
2. Kits de instalação do novo sistema/versão, com suas instruções de uso.
3. Manuais de utilização do novo sistema/versão.
4. Material base de treinamento dos usuários.
Desenvolvimento de sistemas
Projetos organizacionais
PO1 - Projeto organizacional 1
Objetivo :
=== Orientar a fase de arquitetura no projeto de novos sistemas/versões.
Histórico :
=== Matriz resumo de estudo - Pontos 1/...
Descrição sumária :
Documentos de detalhamento :
=== Matriz0.doc
=== DFD : P0.gfc / P1.gfc
=== DER : Der.gfc
PO2 - Projeto organizacional 2
Objetivo :
=== Orientar a fase de projeto de novos sistemas/versões.
Histórico :
=== Matriz resumo de estudo - Pontos 5/...
Descrição sumária :
Documentos de detalhamento :
=== Matriz0.doc
=== DFD : P0.gfc / P2.gfc
=== DER : Der.gfc
Nas páginas seguintes temos :
1. Um exemplo de uma Matriz de Estudo que explora alguns problemas que normalmente ocorrem em um processo de desenvolvimento de sistemas. Observe que os Projetos Organizacionais referidos na Matriz, encontram-se exemplificados nas páginas anteriores.
2. Um exemplo de uma sequência de atividades que compôem um projeto de sistema modelo.
Projetos organizacionais
PO1 - Projeto organizacional 1
Objetivo :
=== Orientar a fase de arquitetura no projeto de novos sistemas/versões.
Histórico :
=== Matriz resumo de estudo - Pontos 1/...
Descrição sumária :
Documentos de detalhamento :
=== Matriz0.doc
=== DFD : P0.gfc / P1.gfc
=== DER : Der.gfc
PO2 - Projeto organizacional 2
Objetivo :
=== Orientar a fase de projeto de novos sistemas/versões.
Histórico :
=== Matriz resumo de estudo - Pontos 5/...
Descrição sumária :
Documentos de detalhamento :
=== Matriz0.doc
=== DFD : P0.gfc / P2.gfc
=== DER : Der.gfc
Nas páginas seguintes temos :
1. Um exemplo de uma Matriz de Estudo que explora alguns problemas que normalmente ocorrem em um processo de desenvolvimento de sistemas. Observe que os Projetos Organizacionais referidos na Matriz, encontram-se exemplificados nas páginas anteriores.
2. Um exemplo de uma sequência de atividades que compôem um projeto de sistema modelo.
Matriz de Estudo - conteúdos
Estrutura de Projeto- conteúdos
Evolução de Análise Estruturada para Análise Orientada à
Objetos
28/06/1999
A motivação para este estudo é responder
as seguintes perguntas :
- Por que uma equipe deve adotar a análise
orientada a objetos ?
- Como a análise / projeto orientada a objetos
colabora no esforço para padronizar e otimizar a engenharia de conhecimentos
(engenharia de informações) ?
- Como aproveitar o investimento e
conhecimento da organização, representado com base na análise estruturada, na
transição para análise orientada à objetos ?
Orientação à objetos
(conceito em disseminação atualmente - 28/06/1999).
Análise,
projeto, programação e manutenção como um contínuo refinamento do conhecimento
sobre os objetos tratados na área de negócios em estudo.
Analogia é a
indústria automobilística, onde um novo veículo é composto por montagem de
componentes disponíveis no mercado e utilizáveis em vários modelos.
Modularidade radical : objeto é o conjunto de dados / propriedades,
eventos e métodos referentes à uma entidade representada no sistema.
Ferramentas de análise e projeto : fichas de especificação de objetos e
diagramas de transição de estados de um sistema.
Construção de
aplicações por composição de objetos existentes (já testados), com objetos
específicos, desenvolvidos para a aplicação.
Manutenção facilitada por
características de encapsulamento (correções e/ou aperfeiçoamento de funções de
objetos ficam disponíveis para todos os sistemas que os utilizem, novas funções
para objetos não impactam sistemas já implantados.
Eliminação da
necessidade de referências cruzadas e controle de versões, uma vez que uma
aplicação passa a ser composta pela interação de objetos com comportamento
especificado no repositório de objetos.
Conversão de
especificações existentes em Análise Estruturada para implantação Orientada à
Objetos em ambiente Cliente - Servidor.
Para cada entidade
informacional identificada nos Diagramas de Fluxo de Dados e Diagramas de
Entidades e Relacionamentos, definir um Objeto de Dados.
Para cada
entidade humana identificada nos Diagramas de Fluxo de Dados e Diagramas de
Entidades e Relacionamentos, definir um Objeto de Interface.
Para cada
fluxo de dados entre um processo e uma entidade informacional, de um Diagrama de
Fluxo de Dados, definir um método para um Objeto de Dados, que deverá ser
implantado como um procedimento armazenado no servidor (stored procedure, no
caso do SQL-Server), referenciada à estrutura de dados que acessa.
Para
cada fluxo de dados entre um processo e uma entidade humana, de um Diagrama de
Fluxo de Dados, definir um método para um Objeto de Interface, que deverá ser
disponibilizado para as estações de interface do sistema.
Ou seja, os
processos de nível mais baixo (micro-especificações), são convertidos em
conjuntos de :
• métodos de objetos de interface (interação com pessoas),
que fazem a captura e apresentação de dados, e
• métodos de objetos de
dados (interação com dados), que fazem a atualização e recuperação de dados em
estruturas de dados internas ou externas ao escopo do sistema (interação entre
sistemas).
Exemplos :
Objetos de Interface (estação) Objetos de
dados (servidor)
obiFatura.Apresentação sp_obdFatura.Recupera
obiFatura.Inclusão sp_obdFatura.Inclui
obiFatura.Alteração
sp_obdFatura.Altera
As triggers e stored procedures (em ambiente
SQL-Server), representam as regras de negócios associadas aos objetos de dados
e, através da interação entre analistas de negócios e administradores de dados,
na criação das triggers, stored procedures e índices, faz-se a adequação dos
acessos à dados, necessários às aplicações, e otimização de performance do(s)
servidor(es) de objetos de dados, evitando-se as desagradáveis surpresas de
degradação de performance, que a submissão livre de comandos SQL, pode causar em
qualquer Sistema de Gerenciamento de Banco de Dados.
Observação : esta
abordagem deve ser considerada nas fases (G) e (H) da estrutura de projeto
modelo para análise de sistemas, proposta no texto Metodologia de
Desenvolvimento de Sistemas da CEPRO – Consultoria em Informática.
Bibliografia de referência :
1. Gane,Chris / Sarson,Trish
Análise Estruturada de Sistemas
Livros Técnicos e Cientificos Editora S.A. - 1984
2. Gane,Chris
Desenvolvimento Rápido de Sistemas
Livros Técnicos e Cientificos Editora S.A. - 1988
3. Shiller, Larry
Excelência em Software - (Série Yourdon Press)
Makron Books - 1992
4. Keller,Robert
Análise Estruturada na Prática
McGrawHill - 1990
5. Bohl,Marilyn
Guia para Programadores
Editora Campus - 1983
1. Gane,Chris / Sarson,Trish
Análise Estruturada de Sistemas
Livros Técnicos e Cientificos Editora S.A. - 1984
2. Gane,Chris
Desenvolvimento Rápido de Sistemas
Livros Técnicos e Cientificos Editora S.A. - 1988
3. Shiller, Larry
Excelência em Software - (Série Yourdon Press)
Makron Books - 1992
4. Keller,Robert
Análise Estruturada na Prática
McGrawHill - 1990
5. Bohl,Marilyn
Guia para Programadores
Editora Campus - 1983
____________________________________________________________________________
RE: Evolução de AE => Análise Orientada à
Objetos (n Camadas)
18/9/2009 11:53 AM
quote:Evolução de Análise Estruturada para Análise Orientada à Objetos
Na mensagem acima, por
razões didáticas, em relação ao tópico tratado (evolução da análise de
sistemas), só foram tratadas duas camadas de objetos:
Cliente e Servidor.
No mínimo, seria necessário considerar
mais uma camada: a camada de negócio, que permite retirar as
Regras de Negócio dos Objetos de Interface (lado Cliente da
aplicação) e dos Objetos de Dados (lado Servidor da aplicação, também
conhecida como camada de persistência).
Conforme a Arquitetura
Técnica da aplicação em desenvolvimento, serão definidas as camadas de
objetos necessárias.
____________________________________________________________________
[Análise de Sistemas - Evolução - Estruturada /
Objeto / SOA] Mensagens relacionadas 18/9/2009 12:27 PM
TIC - Macro visão de
rumo:
=== Todos os Fóruns >> [Fóruns de GC em áreas de
aplicação] >> GC na área de TI >> TIC - Macro visão de rumo
SOA - referências :
=== Todos os Fóruns >>
[Fóruns de GC em áreas de aplicação] >> GC na área de TI >> SOA -
referências
___________________________________________________________________
RE: Análise de Sistemas - Evolução ... (em resposta à claudioprospero)
vclaport 10/11/2009 3:55 PM
Segue uma
sugestão para este tópico ... Acho que poderíamos discutir neste tópico os
"links" da Gestão do Conhecimento com o desenvolvimento de software, a forma
como esta mudança de paradigma pode ter influenciado em cada etapa do
desenvolvimento de software, as metodologias, a própria forma de enxergar o
software. Que tal a sugestão ? Neste caso, acho que para cada item que você
postou, valeria ter algum questionamento, alguma discussão ... Que tal?
Abs
Viviane
__________________________________________________
RE: [discutir neste tópico os "... (em resposta à vclaporti)
11/11/2009 6:15 PM
Olá, Viviane.
Se compreendi
corretamente sua proposta, ela relaciona-se com uma conversa recorrente entre o
Sérgio Storch e eu sobre o uso deste fórum.
Tenho procurado utilizar
este fórum (e outros de que participo), de acordo com meu entendimento do Modelo
SECI, de Nonaka e Takeuti[1] , como um BA [1], no qual busco Socializar,
Externalizar, Combinar e Internalizar Conhecimentos, ciclicamente e com contínuo
aumento de compreensão sobre alguns tópicos relacionados a Tecnologia da
Informação e Comunicação.
Pelo exposto acima eu creio que nossas
postagens neste e em outros fóruns já atendem suas sugestões. (Eu tenho uma
visão de GC como Ações e Valores que promovam a Geração e Compartilhamento de
Conhecimento, não como atividade de Administração, ou Gestão, do Processo
de Geração e Compartilhamento de Conhecimento, algo como "pedalar se aprende
pedalando")
Gostaria da sua opinião e dos demais pares sobre o assunto.
Se porventura não compreendi corretamente sua proposta, desculpe-me e
esclareça-me melhor, talvez com algum exemplo.
Um abraço.
Claudio
[1] BA
SECI Model Nonaka Takeuchi
http://www.12manage.com/methods_nonaka_seci_pt.html
http://www.12manage.com/i_ki_pt.html
Claudio
[1] BA
SECI Model Nonaka Takeuchi
http://www.12manage.com/methods_nonaka_seci_pt.html
http://www.12manage.com/i_ki_pt.html
_____________________________________________________________
RE: [discutir neste tópico os "... (em resposta à claudioprospero)vclaport 12/11/2009 9:00 AM
Olá, Claudio !
Acho que não me
compreendeu direito não ... Aliás, mais que isso, seu comentário parece ter um
tom de quem "compreendeu mal " minha proposta e levou para o lado pessoal.
A minha sugestão era que, a cada tópico que você postou como seqüência
deste fórum, que levantássemos questões envolvendo o item e a Gestão do
Conhecimento, discutíssemos tanto prática quanto técnica e teoricamente o que
mudou, ou pode mudar frente ao "paradigma" da GC, seria algo complementar ao que
começamos a fazer no tópico de Metodologias Ágeis.
Por exemplo, no tópico
relacionado às Metodologias de Desenvolvimento, poderíamos comparar os modelos
de MDS que existem ( inclusive ágil) e em que eles "atenderiam" à Espiral de
Nonaka, às propostas de Prusak, a outras propostas como a daquele artigo que
enviei, etc. Poderíamos refletir e discutir sobre o que é mais "vantajoso" para
determinados contextos e para quem ( do ponto de vista de disseminação do
conhecimento, etc.).
Seja neste ou em outro fórum, penso que há muito a
explorar aí. A sua iniciativa foi ótima, as comparações muito legais mas poderia
ser o ponto de partida para várias discussões, entende ?
Abraços a
todos.
Viviane
_______________________________________________
RE: [discutir neste tópico os "... (em resposta à vclaporti)
12/11/2009 6:32 PM
quote:Acho que não me compreendeu direito não ... Aliás, mais que isso, seu comentário parece ter um tom de quem "compreendeu mal " minha proposta e levou para o lado pessoal.
Viviane, saudações.
De modo algum me senti
criticado por suas colocações, se for o significado de "levou para o lado
pessoal". Pelo contrário: agradeço e me alegro com a participação e
contribuição, principalmente as críticas, em relação à minhas opiniões, que me
permitam corrigir meus erros de percepção / compreensão sobre os assuntos.
Minha intenção com a explicação do uso dos fóruns foi uma simples
explicação. Tentei demonstrar a perspectiva que orienta meu uso deste fórum. Não
significando que considere minha forma melhor do que a de outros. O fórum é
nosso, de todos que se dispuserem a participar, e é livre, dentro dos limites da
civilidade, para várias perspectivas de análise dos assuntos.
quote:Por exemplo, no tópico relacionado às Metodologias de Desenvolvimento, poderíamos comparar os modelos de MDS que existem ( inclusive ágil) e em que eles "atenderiam" à Espiral de Nonaka, às propostas de Prusak, a outras propostas como a daquele artigo que enviei, etc. Poderíamos refletir e discutir sobre o que é mais "vantajoso" para determinados contextos e para quem ( do ponto de vista de disseminação do conhecimento, etc.).Seja neste ou em outro fórum, penso que há muito a explorar aí. A sua iniciativa foi ótima, as comparações muito legais mas poderia ser o ponto de partida para várias discussões, entende ?
Será muito
gratificante se minhas postagens derem inicio à vários diálogos e análises sobre
MDS e suas maiores ou menores aderências(?) às propostas dos autores citados por
você.
Qual sua opinião, e dos demais que nos leêm, sobre a forma para
conduzir estes diálogos [a]? (Não gosto muito do termo discussão que, em minha
opinião, pressupõe posições antagônicas, enquanto diálogos pressupõe uma troca
de informações onde todos nós procuramos compreender nossos vários pontos de
vista sobre o objeto de diálogo, por exemplo: MDS e GC(autor x)).
[a]
Exemplos (forma para conduzir estes diálogos):
>> um tópico para
cada MDS com respostas analisando sua aderência às propostas de um dado autor.
>> um tópico para cada autor com respostas analisando como cada
MDS contribui para as propostas do autor.
Um abraço.
Claudio
___________________________________________________________
RE: [discutir neste tópico os "... (em resposta à claudioprospero)
vclaport 13/11/2009 9:44 AM
Que ótimo! Parece que agora nos entendemos .. .:)
Uma
sugestão seria vc até mesmo começar estes diálogos com a respectiva mensagem que
vc postou neste fórum. Acho quase todas as postagens dariam um diálogo separado,
pois há mta coisa pra comentar...
Uma sugestão para abrir os diálogos
seria : um sobre MDS, outro sobre construção e manutenção de sistemas, outro
sobre requisitos, outra sobre modelagens utilizadas, outro sobre as fases de
implementação e testes. outra referente à evolução de AE para AOO.
Esta
é só uma sugestão ...
OBS: Só pra entender... Não disse e nem quis dizer
que sua percepção estaria errada, apenas disse que podemos dialogar sobre estes
temas, blz?
Abs,
Viviane
_____________________________________________________________
[GC em TIC] Contribuição das Metodo... (em resposta à vclaporti)
13/11/2009 5:55 PM
Viviane, obrigado.
Seus comentários estimularam uma
reflexão focada sobre algumas considerações, surgidas em conversas com colegas,
sobre MDSI. Como resultado consegui estruturar o texto abaixo que submeto aos
comentários dos pares.
Abraços.
Claudio
Contribuição das Metodologias de Desenvolvimento de Sistemas de
Informações (MDSI) para Gestão do Conhecimento (GC) em Tecnologia da Informação
e Comunicação (TIC).
Definição de
MDSI:
Conjunto de Processos e Padrões de Artefatos
utilizados para documentar os resultados destes Processos. Ou seja, um Método de
Trabalho (Processos) e um Padrão de Representação Simbólico (Artefatos) do
Objeto deste trabalho, no caso, um Sistema de Informações.
Uma dada MDSI
(exemplos: Análise Estruturada, Essencial, Orientada a Objetos) é a parte da
Engenharia de Software que padroniza os Processos e Artefatos para a criação ∕
aquisição, refinamento, armazenagem, transferência ∕ compartilhamento e
utilização do conhecimento, sobre um determinado Sistema de Informações que
esteja sendo desenvolvido.
Exemplo de tópicos de
Gestão do Conhecimento e de seu atendimento por uma MDSI
genérica:
Criação ∕ Aquisição de Conhecimento:
• Levantamento de Requisitos do Sistema de Informações
•
Definição da Arquitetura do Sistema
• Definição de Estruturas de Dados e
Funcionalidades que atendam aos Requisitos do Sistema de Informações, de acordo
com a Arquitetura definida
Refinamento de Conhecimento:
•
Definição de Estruturas de Dados e Funcionalidades que atendam aos Requisitos do
Sistema de Informações, de acordo com a Arquitetura de Sistema definida. Este
processo de refinamento ocorre ao longo dos Processos previstos pela MDSI, por
exemplo, durante os levantamentos de informações, preenchimento e análise
conjunta dos Artefatos (para detectar incoerências entre visões do Sistema de
Informações, representadas em dois ou mais Artefatos), revisões, dos Artefatos,
na equipe de desenvolvimento e / ou com os apoiadores / interessados
(stakeholder) no Projeto de Desenvolvimento de Sistema de Informações em
execução.
Armazenagem de Conhecimento:
• Preenchimento
dos Artefatos, ou Documentos, definidos pela MDSI.
Transferência ∕
Compartilhamento de Conhecimento:
• Utilização dos Artefatos,
Documentos, da versão anterior e da versão em desenvolvimento, do Sistema de
Informações, como objeto de análise.
• Revisões, dos Artefatos, na
equipe de desenvolvimento e / ou com os apoiadores / interessados
(stakeholder) no Projeto de Desenvolvimento de Sistema de Informações em
execução.
Utilização do conhecimento:
• Utilização dos
Artefatos, Documentos, da versão anterior e da versão em desenvolvimento, do
Sistema de Informações, como objeto de análise.
• Revisões, dos
Artefatos, na equipe de desenvolvimento e / ou com os interessados (stakholder)
do Projeto de Desenvolvimento de Sistema em execução. Processo de validação do
conhecimento produzido, representado (explicitado) nos Artefatos da MDSI.
• Utilização dos Artefatos, Documentos, da versão em desenvolvimento, do
Sistema de Informações, como evidências do progresso do Projeto de
Desenvolvimento de Sistema em execução (Entregáveis, Eventos de Faturamento).
• Utilização dos Artefatos, Documentos, da versão em desenvolvimento, do
Sistema de Informações, como insumo para produção de materiais de Comunicação
sobre o Sistema de Informações em Desenvolvimento.
__________________________________________________________
RE: Engenharia de software - segund... (em resposta à claudioprospero)
claudioprospero 16/11/2009 1:58 PM
Engenharia de software
Origem: Wikipédia, a enciclopédia livre. (Consulta em 16/11/2009)
O texto tem vários links não reproduzidos
aqui
quote:O artigo ou secção Engenharia de software orientado a objetos deverá ser fundido neste artigo ou secção.Se não concorda, discuta sobre esta fusão na página de discussão deste artigo.Este artigo ou secção contém uma lista de fontes ou uma única fonte no fim do texto, mas estas não são citadas no corpo do artigo (desde Junho de 2009)
Você pode melhorar este artigo introduzindo notas de
rodapé citando as fontes, inserindo-as no corpo do texto quando necessário.
quote:A Wikipédia possui os portais:Portal das tecnologias de informação
Engenharia de
software é uma área do conhecimento da computação voltada para a
especificação, desenvolvimento e manutenção de sistemas de software aplicando
tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando
organização, produtividade e qualidade.
Atualmente, essas tecnologias e
práticas englobam linguagens de programação, banco de dados, ferramentas,
plataformas, bibliotecas, padrões, processos e a questão da Qualidade de
Software.
Os fundamentos científicos para a engenharia de software
envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro
especificar, projetar, implementar e manter sistemas de software, avaliando e
garantindo suas qualidades. Além disso, a engenharia de software deve oferecer
mecanismos para se planejar e gerenciar o processo de desenvolvimento de um
sistema de informação Sistema Computacional, pois ambos se confundem.
Índice
1 Definição
2 Áreas de Conhecimento
3 Processo
de Software
3.1 Modelos de Processo de Software
3.2 Modelos de
Maturidade
4 Metodologias e Métodos
4.1 Modelagem
5 Ferramentas,
Tecnologias e Práticas
5.1 Ferramentas
6 Gerência de Projetos
6.1
Planejamento
6.2 Análise de Requisitos
6.3 Gestão
7 Histórico
8
ES no Presente e Tendências
9 Referências
10 Bibliografia
11
Ligações externas
12 Ver também
Definição
Segundo
Friedrich Ludwig Bauer, "Engenharia de Software é a criação e a utilização de
sólidos princípios de engenharia a fim de obter software de maneira econômica,
que seja confiável e que trabalhe eficientemente em máquinas reais". O próprio
significado de engenharia já traz os conceitos de criação, construção, análise,
desenvolvimento e manutenção.
A Engenharia de Software se concentra nos
aspectos práticos da produção de um sistema de software, enquanto a ciência da
computação estuda os fundamentos teóricos dos aspectos computacionais.
O
termo foi criado na década de 1960 e utilizado oficialmente em 1968 na NATO
Conference on Software Engineering (Conferência sobre Engenharia de Software da
OTAN). Sua criação surgiu numa tentativa de contornar a crise do software e dar
um tratamento de engenharia (mais sistemático e controlado) ao desenvolvimento
de sistemas de software complexos. Um sistema de software complexo se
caracteriza por um conjunto de componentes abstratos de software (estruturas de
dados e algoritmos) encapsulados na forma de procedimentos, funções, módulos,
objetos ou agentes e interconectados entre si, compondo a arquitetura do
software, que deverão ser executados em sistemas computacionais.
Os
fundamentos científicos envolvem o uso de modelos abstratos e precisos que
permitem ao engenheiro especificar, projetar, implementar e manter sistemas de
software, avaliando e garantindo suas qualidades. Além disto, deve oferecer
mecanismos para se planejar e gerenciar o processo de desenvolvimento. Empresas
desenvolvedoras de software passaram a empregar esses conceitos sobretudo para
orientar suas áreas de desenvolvimento, muitas delas organizadas sob a forma de
Fábrica de Software.
A Engenharia de Sistemas é uma área mais ampla por
tratar de todos os aspectos de sistemas baseados em computadores, incluindo
hardware e engenharia de processos além do software.
Áreas de
Conhecimento
Segundo o SWEBOK (Corpo de Conhecimento da Engenharia de
Software), versão 2004, as áreas de conhecimento da Engenharia de Software são:
> Requisitos (Requirements) de Software
> Projeto (Design) de
Software
> Construção (Construction) de Software
> Teste (Testing)
de Software
> Manutenção (Maintenance) de software
> Gerência de
Configuração de Software
> Gerência de Engenharia de Software
>
Processos de Engenharia de Software
> Ferramentas e Métodos de Engenharia
de Software
> Qualidade (Quality) de Software
Conforme Pressman,
a Engenharia de Software (ES) é uma tecnologia em camadas. E a base de todas
essas camadas é o foco na qualidade do software desenvolvido. Portanto,
inclusive do ponto de vista didático, é interessante estudarmos a ES em suas
camadas de Processo, Métodos e Ferramentas.
Processo de Software
Ver artigo principal: Processos de Engenharia de Software
Processo de software, ou processo de engenharia de software, é uma
seqüência coerente de práticas que objetiva o desenvolvimento ou evolução de
sistemas de software. Estas práticas englobam as atividades de especificação,
projeto, implementação, testes e caracterizam-se pela interação de ferramentas,
pessoas e métodos.
SEE e PSEE são os ambientes voltados ao
desenvolvimento e manutenção de processos. O projeto ExPSEE é uma continuação
dos estudos de processos, principalmente do ambiente PSEE.
Devido ao uso
da palavra projeto em muitos contextos, por questões de clareza, há vezes em que
se prefira usar o original em inglês design.
Modelos de Processo de
Software
Um modelo de processo de desenvolvimento de software, ou
simplesmente modelo de processo, pode ser visto como uma representação, ou
abstração dos objetos e atividades envolvidas no processo de software. Além
disso, oferece uma forma mais abrangente e fácil de representar o gerenciamento
de processo de software e consequentemente o progresso do projeto.
Exemplos de alguns modelos de processo de software;
> Modelos
ciclo de vida
> Sequencial ou Cascata (do inglês waterfall) - com fases
distintas de especificação, projeto e desenvolvimento.
> Desenvolvimento
iterativo e incremental - desenvolvimento é iniciado com um subconjunto simples
de Requisitos de Software e interativamente alcança evoluções subseqüentes das
versões até o sistema todo estar implementado
> Evolucional ou
Prototipação - especificação, projeto e desenvolvimento de protótipos.
>
V-Model - Parecido com o modelo cascata, mas com uma organização melhor, que
permite que se compare com outros modelos mais modernos.
> Espiral -
evolução através de vários ciclos completos de especificação, projeto e
desenvolvimento.
> Componentizado - reuso através de montagem de
componentes já existentes.
> Formal - implementação a partir de modelo
matemático formal.
> Ágil
> RAD
> Quarta geração
Modelos de Maturidade
Os modelos de maturidade são um
metamodelo de processo. Eles surgiram para avaliar a qualidade dos processos de
software aplicados em uma organização (empresa ou instituição). O mais conhecido
é o Capability Maturity Model Integration (CMMi), do Software Engineering
Institute - SEI.
O CMMi pode ser organizado através de duas formas,
contínua e estagiada. Pelo modelo estagiado, mais tradicional e mantendo
compatibilidade com o CMM, uma organização pode ter sua maturidade medida em 5
níveis:
Nível 1 - Caótico;
Nível 2 - Capacidade de repetir sucessos
anteriores pelo acompanhamento de custos, cronogramas e funcionalidades;
Nível 3 - O processo de software é bem definido, documentado e padronizado;
Nível 4 - Realiza uma gerência quantitativa do processo de software e do
produto;
Nível 5 - Usa a informação quantitativa para melhorar continuamente
e gerenciar o processo de software.
O CMMi é um modelo de maturidade
recentemente criado com o fim de agrupar as diferentes formas de utilização que
foram dadas ao seu predecessor, o CMM.
O (MPS.BR), ou Melhoria de
Processos do Software Brasileiro, é simultaneamente um movimento para a melhoria
e um modelo de qualidade de processo voltada para a realidade do mercado de
pequenas e médias empresas de desenvolvimento de software no Brasil.
Metodologias e Métodos
O termo metodologia é bastante
controverso nas ciências em geral e na Engenharia de Software em particular.
Muitos autores parecem tratar metodologia e método como sinônimos, porém seria
mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam
uma gama de métodos que utilizam ferramentas e práticas diferenciadas para
realizar algo.[1]
Assim teríamos, por exemplo, a Metodologia
Estruturada, na qual existem vários métodos, como Análise Estruturada e Projeto
Estruturado (muitas vezes denominados SA/SD, e Análise Essencial). Tanto a
Análise Estruturada quanto a Análise Essencial utilizam a ferramenta Diagrama de
Fluxos de Dados para modelar o funcionamento do sistema.
Metodologia
Estruturada
> Análise Estruturada
> Projeto Estruturado
> Programação Estruturada
> Análise Essencial
> SADT
> DFD - Diagrama de Fluxo de Dados
> MER - Modelo de Entidades e
Relacionamentos
Metodologia Orientada a Objetos
>
Orientação a Objetos
> Rational Unified Process ( RUP )
Desenvolvimento ágil de software
> Feature Driven
Development ( FDD )
> Enterprise Unified Process (EUP)
> Scrum
(Scrum)
> Crystal (Crystal Clear, Crystal Orange, Crystal Orange Web)
> Programação extrema ( XP )
Outras Metodologias
>
Microsoft Solution Framework ( MSF )
Modelagem
A abstração do
sistema de software através de modelos que o descrevem é um poderoso instrumento
para o entendimento e comunicação do produto final que será desenvolvido.
A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre
simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a
precisão) do modelo.
Para a modelagem podemos citar 3 métodos:
> Análise estruturada, criada por Gane & Searson;
>
Análise essencial, criada por Palmer & McMenamin e Ed. Yourdon;
> UML
criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh (veja exemplos).
Atualmente a modelagem mais recomendada, e sendo a mais comum, é a
utilização da linguagem UML.
Ferramentas, Tecnologias e
Práticas
A engenharia de software aborda uma série de práticas e
tecnologias, principalmente estudadas pela ciência da computação, enfocando seu
impacto na produtividade e qualidade de software.
Destacam-se o estudo
de linguagem de programação, banco de dados e paradigmas de programação, como:
> Programação estruturada
> Programação funcional
>
Programação orientada a objetos
> Componentes de Software
>
Programação orientada a aspecto
Ferramentas
Outro ponto
importante é o uso de ferramentas CASE (do inglês Computer-Aided Software
Engineering). Essa classificação abrange toda ferramenta baseada em computadores
que auxiliam atividades de engenharia de software, desde a análise de requisitos
e modelagem até programação e testes.
Os ambientes de desenvolvimento
integrado (IDEs) têm maior destaque e suportam, entre outras coisas:
> Editor
> Compilador
> Debug
> Geração de
código
> Modelagem
> Deploy
> Testes não automatizados
> Testes automatizados
> Refatoração (Refatoring)
> Gestão
de Riscos nos projectos de Software
> Uso da Prototipagem na Eng. de
Requisitos
Gerência de Projetos
A gerência de projetos se
preocupa em entregar o sistema de software no prazo e de acordo com os
requisitos estabelecidos, levando em conta sempre as limitações de orçamento e
tempo.
A gerência de projetos de software se caracteriza por tratar
sobre um produto intangível, muito flexível e com processo de desenvolvimento
com baixa padronização.
Planejamento
O planejamento de um
projeto de desenvolvimento de software inclui:
> Análise Econômica de
Sistemas de Informações
> organização do projeto (incluindo equipes e
responsabilidades)
> estruturação das tarefas (do inglês WBS - work
breakdown structure)
> cronograma do projeto (do inglês project schedule)
> análise e gestão de risco
> estimativa de custos
Essas
atividades sofrem com dificuldades típicas de desenvolvimento de software. A
produtividade não é linear em relação ao tamanho da equipe e o aumento de
produtividade não é imediato devido aos custos de aprendizado de novos membros.
A diminuição de qualidade para acelerar o desenvolvimento constantemente
prejudica futuramente a produtividade.
A estimativa de dificuldades e
custos de desenvolvimentos são muito difíceis, além do surgimento de problemas
técnicos. Esses fatores requerem uma análise de riscos cuidadosa.
Além
da própria identificação dos riscos, há que ter em conta a sua gestão. Seja
evitando, seja resolvendo, os riscos necessitam ser identificados (estimando o
seu impacto) e devem ser criados planos para resolução de problemas.
Análise de Requisitos
As atividades de análise concentram-se
na identificação, especificação e descrição dos requisitos do sistema de
software. Em resumo, requisito é uma necessidade que o software deve cumprir.
Há várias interpretações e classificações sobre requisitos, entre elas:
> funcional
> não funcional
> de usuário
> de
sistema
É comum que o cliente não saiba o que ele realmente deseja, que
haja problemas na comunicação e ainda que haja mudança constante de requisitos.
Todos esses fatores são recrudescidos pela intangibilidade sobre características
de sistemas de software, principalmente sobre o custo de cada requisito.
> Estudo de Viabilidade (Levantamento de Requisitos)
A
Engenharia de requisitos é um processo que envolve todas as atividades exigidas
para criar e manter o documento de requisitos de sistema (SOMMERVILLE). Segundo
RUMBAUGH, alguns analistas consideram a engenharia de Requisitos como um
processo de aplicação de um método estrutura como a analise orientada a objetos.
No entanto, a Engenharia de requisitos possui muito mais aspectos do que os que
estão abordados por esses métodos.
Abaixo um pequeno Processo de
Engenharia de Requisitos (SOMMERVILLE).
Estudo da viabilidade ->
"Relatório de Viabilidade" Obtenção e Analise de Requisitos -> "Modelos de
Sistema" Especificação de Requisitos -> "Requisitos de Usuário e de Sistema"
Validação de Requisitos -> "Documento de Requisitos"
O primeiro
processo a ser realizado num Sistema novo é o Estudo de Viabilidade. Os
resultados deste processo devem ser um relatório com as recomendações da
viabilidade técnica ou não da continuidade no desenvolvimento do Sistema
proposto. Basicamente um estudo de viabilidade, embora seja normalmente rápido,
deverá abordar fundamentalmente as seguintes questões:
O Sistema
proposto contribui para os objetivos gerais da organização? O Sistema poderá ser
implementado com as tecnologias dominadas pela equipe dentro das restrições de
custo e de prazo? Ou precisa de treinamentos adicionais? O Sistema pode ser
integrado, e é compatível com os outros sistemas já em operação?
Gestão
> Pessoal
> Produto
> Processo
> Projeto
> Material
Histórico
A Engenharia de
Software (ES) surgiu em meados dos anos 1970 numa tentativa de contornar a crise
do software e dar um tratamento de engenharia (mais sistemático e controlado) ao
desenvolvimento de sistemas de software complexos. Um sistema de software
complexo se caracteriza por um conjunto de componentes abstratos de software
(estruturas de dados e algoritmos) encapsulados na forma de procedimentos,
funções, módulos, objetos ou agentes interconectados entre si, compondo a
arquitetura do software, que deverão ser executados em sistemas computacionais.
ES no Presente e Tendências
Atualmente existe um destaque
todo especial para a Engenharia de Software na Web. Também utilizado por
Presmann a sigla WebE, é o processo usado para criar WebApps (aplicações
baseadas na Web) de alta qualidade. Embora os princípios básicos da WebE sejam
muito próximos da Engenharia de Software clássica, existem peculiaridades
específicas e próprias.
Com o advento do B2B (e-business) e do B2C
(e-commerce), e ainda mais com aplicações para a Web 2.0, maior importância
ficou sendo esse tipo de engenharia. Normalmente adotam no desenvolvimento a
arquitetura MVC (Model-View-Controller).
Referências
↑ Veja
mais detalhes em Metodologia (engenharia de software)
Bibliografia
MAGELA, Rogerio. Engenharia de Software
Aplicada: Princípios (volume 1). Alta Books. 2006.
MAGELA, Rogerio.
Engenharia de Software Aplicada: Fundamentos (volume 2). Alta Books. 2006.
MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no
Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5
PRESSMAN, Roger. Software Engineering: A Practitioner's Approach, 6ªedição,
Mc Graw Hill, 2005.
ANÁLISE ECONÔMICA DE SISTEMAS DE INFORMAÇÕES. (ISBN
978-85-909374-7-0) Editora Ixtlan. Autor : Sergio Kaminski. Comentário: Mostra
todas as etapas de desenvolvimento do software, relacionando ao lucro,receita e
custo.
Ligações externas
Site dos alunos da Graduação em
Engenharia de Software da Universidade Federal de Goiás - UFG
Bacharelado em Engenharia de Software (Graduação em Engenharia de
Software) Curso superior oferecido pelo Instituto de Informática ---
Universidade Federal de Goiás.
GPES Grupo de Pesquisa em Engenharia de
Software do Departamento de Ciência da Computação da Universidade Federal de
Minas Gerais.
Praxis - Processo de desenvolvimento de software com
enfoque educacional
Software da gerência de OEE
Podcasts bem
interessantes (em português) sobre áreas de interesse da Engenharia de Software
CMMI, MPS.BR, Scrum, Extreme Programming e Lean Software Development
Revista Engenharia de Software Revista sobre Engenharia de Software em
portugues
Graduação em Engenharia de Software na Universidade de
Brasilia - FGANovo Campus da Universidade de Brasília
Ver também
quote:A Wikipédia possui o Portal de engenharia
> Desenvolvimento de software
>
Qualidade de software
> Software Engineering Body of Knowledge
>
Análise Econômica de Sistemas de Informações
> Matriz CRUD
quote:Obtido em "http://pt.wikipedia.org/wiki/Engenharia_de_software"Categoria: Engenharia de software
__________________________________________________________
RE: [GC em TIC] Contribuição das Me... (em resposta à claudioprospero)
vclaport 16/11/2009 2:03 PM
Só para começar este diálogo, seguem nesta mensagem duas
perguntas que venho fazendo na empresa onde trabalho, sempre que eles decidem
falar sobre metodologia e conhecimento.
Sabemos da grande importância de
se ter e seguir uma metodologia, mas a pergunta é : A utilização de artefatos
garante a aquisição, o armazenamento e disseminação do
conhecimento? E o fato de se ter um processo definido, isso garante
a disseminação do conhecimento entre os participantes?
Abraços
Viviane
