-
Desde quando a preocupação com a "crise dosoftware" vem crescendo?
Nos últimos anos.
-
O que é a crise do software?
A crise do software refere-se ao aumento do custo de desenvolvimento de software, aliado a falha crescente de sistemas de software para entregar resultados aos seus usuários.
-
Cite um exemplo de projeto onde a "crise do software" pode ser percebida de maneira clara.
Um exemplo de um projeto de software caro e falho é o sistema produzido pelo departamento de veículos a motor de um estado americano. O sistema custou 43 milhões de dolares e nunca foi usado.
-
Qual é o resultado de um percentual significativo do desenvolvimento de software?
Não entrega do produto ou entrega de um produto que não atende o que se espera dele.
-
Quais as razões para a crise do software?
- Sistemas cada vez mais complexos
- Mais e mais sistemas distribuídos
- Código legado
- Ciclos de desenvolvimento mais curtos
- Requisitos iniciais mal definidos
- Má gestão de riscos
- Testes inadequados
-
O que significa "sistemas cada vez mais complexos"?
"Sistemas cada vez mais complexos" significa que as novas tecnologias tem permitido o desenvolvimento de características complexas e com isso aumenta, proporcionalmente, as expectativas dos usuários de sistemas. Esta é a principal causa da crise do software.
-
O que significa "mais e mais sistemas distribuídos"?
Significa que existem cada vez mais sistemas distribuídos através de LANs, WANs e mesmo a Internet adicionando níveis de dificuldades para os desenvolvedores. Projetos de software são muitas vezes tão grande e complexos que uma pessoa não tem uma visão clara de todo o sistema que deve ser desenvolvido. Isto resulta em desenvolvedores que produzem aplicações elaboradas tentando fazer muito e acabam deixando de atender as necessidades dos clientes.
-
Sobre o "código legado" podemos dizer que de que forma ele contribui para a crise do software?
A necessidade de integrar código legado com a nova tecnologia geralmente aumenta a complexidade dos projectos de desenvolvimento de software. Este problema pode ser agravado pelo fato de que os desenvolvedores originais não estão mais com a empresa.
-
Sobre os "ciclos de desenvolvimento mais curtos", podemos dizer que ele influencia a crise de software de que maneira?
Os ciclos de desenvolvimento mais curtos exigidos por compromissos comerciais colocam mais pressão sobre os desenvolvedores.
-
Sobre os "requisitos iniciais mal definidos", podemos dizer que ele influencia a crise de software de que maneira?
Freqüentemente, os requisitos iniciais para um sistema são mal definidos. Pouco tempo é gasto com os usuários finais do sistema para descobrir o que eles desejam de fato do sistema. Assim, os desenvolvedores não entendem completamente o que eles estão tentando construir. Se as condições de um sistema não são trabalhadas exaustivamente antes de ser desenvolvido, é provável que o sistema não satisfaça as exigências dos utilizadores. Isto pode significar que grandes quantidades de esforço de desenvolvimento pode ir para o lixo.
-
Sobre a "má gestão de riscos", podemos dizer que ela influencia a crise de software de que maneira?
A falta de análise e gestão de riscos ao longo do processo aumenta as chances de que os projetos de software irão falhar.
-
Sobre os "testes inadequados", podemos dizer que eles influenciam a crise de software de que maneira?
É importante verificar desde o início do processo de desenvolvimento de um sistema que será executado corretamente. No entanto, muitas vezes, os teste não ocorrem desde o início até o fim do processo, não garantindo que o sistema será executado corretamente.
-
O que acontece quando um projeto falha no final do processo de desenvolvimento?
Uma quantidade enorme de tempo e recursos foram desperdiçados.
-
A quais tipos de riscos um projeto de software esta exposto?
- Riscos funcionais
- Riscos de recursos
- Riscos arquiteturais
-
O que são riscos funcionais?
É o risco associado com as funcionalidades do software que um projecto enfrenta. Por exemplo, o software vai fazer o que se supõe que ele faça? Ele vai chegar ao mercado no momento correto?
-
O que são riscos de recursos?
São riscos ligados aos recursos do projeto. Por exemplo, haverá número suficiente de pessoas, equipamentos e financiamento para completar o projeto? E será que a organização de desenvolvimento de software sabe lidar com as novas tecnologias?
-
O que são riscos de arquitetura?
Risco arquitetônico diz respeito à arquitetura do sistema. Por exemplo, se o modelo de software de suportará a sua implementação? Os componentes se integraram corretamente?
-
O que a tecnolofia orientada a objetos oferece aos desenvolvedores?
Meios para resolver muitos dos problemas inerentes ao desenvolvimento de software.
-
O que a tecnologia orientada a objetos oferece a usuários, programadores e testadores?
Um único paradigma para que eles usem a mesma linguagem.
-
O que a abordagem orientada a objetos permite?
Permite que o mundo real seja modelado.
-
Qual a facilidade que a abordagem orientada a objetos traz?
Torna mais fácil descrever com precisão os dados e processos empresariais. Tornando mais fácil entender e manter os sistemas.
-
O que a abordagem orientada a objetos facilita através da herança e encapsulamento?
Através da herança a abordagem orientada a objetos facilita a reutilização de código e através do encapsulamento proporciona sistemas com estabilidade, permitindo que pequenas mudanças nos requisitos não exija grandes alterações no sistema.
-
A utilização da abordagem orientada a objetos resolve o problema da crise do software?
Não. Em muitos casos o uso incorreto das técnicas de orientação a objetos leva o foco do projeto para o nível mais baixo de desenvolvimento de sistemas, a códificação, dificultando assim o entendimento do todo. Isto ocorre porque os modelos são desenvolvidos para analisar o mecanismo de implementação subjacentes e não a estrutura da aplicação em termos do que ela deve fazer. Fazendo, em muitos projetos que eles comecem muito cedo a programar, cocnentrando o processo de desenvolvimento em questões de programação. Impedindo o procedimento correto que é antes analisar o sistema como um todo para que possa descobrir o seu propósito antes de iniciar a codificação.
|
|
