Na minha retrospectiva desta disciplina posso afirmar: “Foi muito divertido e prazeroso ministrar este conteúdo a vocês”. Eu tive a oportunidade de conhecer novas pessoas e com certeza novos colegas de profissão. A riqueza desta turma esta na multidisciplinaridade, onde em sala de aula nos tivemos profissionais da área de TI, Saúde, Educação, Engenharias, entre outras.
.jpg)
.jpg)
.jpg)
Para um controle do que deve ser desenvolvido em software nos utilizamos prazo rígido, orçamento rígido e escopo variável, onde após a priorização do escopo nos atacamos os itens mais importantes primeiro, deixando os itens secundários para serem construídos apenas após o termino dos itens mais importantes.
Muitas vezes, vejo desenvolvedores de software desviarem-se de suas tarefas para tentar construir um software que satisfaça às necessidades de seus usuários de um modo eficaz, com cenários tolos do tipo “o que acontecerá se...”. Eles começam a modelar demais o software para resolver todos os problemas imagináveis, com os quais os clientes dificilmente estão preocupados ou acreditam ser tão remotamente provável deles acontecerem que estariam dispostos a correr o risco. Então, por modelarem em excesso, os desenvolvedores também constroem em excesso. Sim, você não quer ser completamente simplista em seu trabalho. É razoável esperar que alguns problemas em banco de dados e falhas de rede, entre outros, realmente ocorram, mas você precisa ser realista quando estiver modelando.
As pessoas mudam suas prioridades devido a vários motivos. À medida que o trabalho no sistema progride, muda a compreensão dos clientes do projeto sobre o domínio do problema e sobre o que você está construindo. O ambiente de negócio sofre alterações. A tecnologia muda no decorrer do tempo, embora nem sempre para melhor. A mudança é uma realidade no desenvolvimento de software que seu processo de software deve refletir. Não há nada de errado em ter um plano de projeto. Na verdade, me preocuparia com qualquer projeto que não o possuísse. Entretanto, o plano deve ser maleável; caso contrário, torna-se rapidamente irrelevante.
Apenas seus clientes podem dizer o que querem. Sim, eles dificilmente acertarão na primeira vez. Sim, eles provavelmente mudarão de idéia. Trabalhar junto com os clientes é difícil, mas é a realidade do trabalho. Ter um contrato com eles é importante, e entender os direitos e as responsabilidades de cada um pode se constituir nos alicerces do contrato, este contrato não é substituto para a comunicação. Os desenvolvedores de sucesso trabalham próximos aos clientes; se esforçam para descobrir o que os clientes necessitam e os educam durante este processo.
Se você perguntar aos usuários se eles querem um documento de 50 páginas descrevendo o que você pretende construir ou o software real, o que você acha que eles escolherão? Minha hipótese é de que em 99 em cada 100 vezes eles escolherão o software. Se este for o caso, não faria mais sentido trabalhar de modo que você produza um software de forma rápida e freqüente, dando a seus usuários o que eles preferem? Além disso, suspeito que os usuários entenderão mais facilmente qualquer software que você produzir do que diagramas técnicos complexos que descrevem seu funcionamento interno ou uma abstração de seu uso, não acha? A documentação tem o seu lugar; escrita de maneira correta, é um guia importante para as pessoas entenderem como e por que o sistema é construído e como trabalhar com ele. Entretanto, nunca esqueça de que o objetivo principal do desenvolvimento de software é criar software, não documentos – de outra forma, nós o chamaríamos de desenvolvimento de documentação.
Equipes constroem sistemas de software e, para fazê-lo, elas precisam trabalhar junto com programadores, testadores, gerentes de projeto, modeladores e clientes. Quem você acha que desenvolveria um sistema melhor: cinco desenvolvedores de software com suas próprias ferramentas trabalhando juntos em uma única sala ou cinco pessoas pouco habilitadas com um processo bem-definido, as mais sofisticadas ferramentas disponíveis e os melhores escritórios que o dinheiro pode comprar? Se o processo fosse razoavelmente complexo, eu apostaria nos desenvolvedores de software, e você? O ponto é que os fatores mais importantes a considerar são as pessoas e como elas trabalham juntas, porque se você não entender isso bem, de nada adiantarão as melhores ferramentas e processos, os quais são importantes, não me entenda mal, mas não tão importante quanto trabalhar efetivamente juntos. Lembre-se do velho adágio: um tolo com uma ferramenta ainda é apenas um tolo. Pode ser difícil para a gerência aceitar isso porque muitas vezes ela quer acreditar que pessoas e tempo, ou homens e meses, são intercambiáveis (Brooks, 1995).
- Os criadores da UML vêem os diagramas como secundários; a essência da UML é o metamodelo. Os diagramas são simplesmente uma apresentação do metamodelo.
- Quase sempre utilizo a UML para fazer esboços. Acho os esboços UML úteis para desenvolvimento e engenharia reversa, tanto na perspectiva conceitual como na de software.
Não sou adepto dos projetos de desenvolvimento detalhados; acredito que é muito difícilfazê-los bem feitos, e eles retardam o trabalho de desenvolvimento. É razoável fazer projetos em nível de interfaces de subsistemas, mas mesmo assim, você deve esperar alterações nestas interfaces, a medida que os desenvolvedores implementam as interações nelas.
- Você não pode olhar um diagrama de UML e dizer exatamente como seria o código equivalente. Entretanto, você pode ter uma idéia aproximada de como ficaria o código.
- Em muitos lugares, diferentes diagramas podem ser úteis, e você não deve hesitar em usar um diagrama que não seja feito com UML, se nenhum diagrama da UML atende o seu propósito.
- Normalmente, a unica maneira de saber se você está no caminho certo é produzir software integrado testado.
- As pessoas dizem que estão fazendo software iterativo, mas na verdade estão usando o processo cascata. Os sintomas são:
a) "Estamos fazendo uma iteração de análise seguida de duas iterações de projeto..."
b) "O código dessa iteração está repleto de erros, mas vamos limpá-lo no final."
- O teste e a integração são as atividades mais difíceis de estimar; portanto, é importante não ter uma atividade aberta como essa no final do projeto.
- Uma técnica comum no caso de iterações é usar um quadro de tempo. Isso obriga uma iteração a ocorrer em um período de tempo fixo. Se você achar que não vai conseguir fazer tudo o que pretendia durante uma iteração, deve deslocar alguns funcionalidades dela; você não deve deslocar a data da iteração. A maioria dos projetos que utilizam desenvolvimento iterativo usam o mesmo período de iteração por todo o projeto; desse modo, você consegue um ritmo de construção regular.
- Na verdade, uma das maiores vantagens do desenvolvimento iterativo é que ele suporta melhorias freqüentes no processo. Ao final de cada iteração, realize uma retrospectiva de iteração, na qual a equipe se reúne para considerar como as coisas ocorreram e como elas podem ser aprimoradas.
- Uma das minhas preocupações com os projetos é que, mesmo para um bom projetista, é muito difícil fazê-los corretamente. Freqüentemente, verifico que meus próprios projetos não sobrevivem intactos ao contato com uma codificação. Ainda considero meus esboços UML úteis, mas não creio que eles possam ser tratados como absolutos.
- Um cenário é uma seqüencia de passos que descreve uma interação entre um usuário e um sistema.
- Um caso de uso é um conjunto de cenários amarrados por um objetivo comum ao usuário.
- As funcionalidades constituem uma boa maneira de repartir um sistema para planejar um projeto iterativo, pelo qual cada iteração implementaria várias funcionalidades. O caso de uso fornecem uma narrativa de como os atores utilizam o sistema. Então, embora as duas técnicas descrevam requisitos, seus propósitos são diferentes.
Lições Aprendidas: Eu nunca fiz Pipa e so consegui fazer com a ajuda de um instrutor. A primeira pipa tinha cara de pipa mas não funcionava. A segunda pipa com a ajuda do instrutor funcionou muito bem.
Durante a produção de pipas foi fácil identificar "padrões utilizados", que eram os nós. Também uma especificação teria ajudado muito, pois a unica coisa que tínhamos era apenas a "visão do produto", mas para quem não possui experiência visão é muito pouco.
Postagens
Comentários
