2.20.2017

TDD What ? New or old ? Good or no ?

Currently or since I know myself as a professional, software failures are largely responsible for costs and time in the software development process.
While it is not possible to remove all existing errors in a given application, it is possible to considerably reduce the number of errors using a more elaborate testing infrastructure, which allows for identifying and removing defects earlier and more effectively.
These defects can result from various causes such as errors of knowledge, communication, analysis, transcription, coding, etc. There are basically three ways to handle software flaws:

1. Fault-avoidance: With appropriate specification, design, implementation and maintenance activities always aiming to avoid failures in the first place. It includes the use of advanced software construction methods, formal methods, and reuse of trusted software blocks.

2. Fault-elimination: Analytical compensation for errors committed during specification, design and implementation. Includes verification, validation and testing.

3. Fault-tolerance: real-time compensation of residual problems such as changes out of specification in the operating environment, user errors, etc.

Due to the fact that fault-avoidance is economically impractical for most companies, the technique of fault elimination is generally adopted by software manufacturers

In the US, do these errors move the software market by approximately 50 billion dollars, and in Brazil and South America? We can see that there is a culture of everything by the result, and after delivery by delivery, in many projects and forgotten the quality be it in the software architecture or in the choice of the project implementation strategy, the DEADLINE is focused by the DEADLINE.
Another point is the bureaucratization of technical activities, process must exist but these should also be support to the objectives and not against the objectives that includes being agile, safe, reusable, practical and that make a culture in the company be it with 10 professionals or with 100 In a company.

The culture of testing is old, as it says in King Chelomoh's Cohelet book, nothing new is just not revealed.

The practice involves the implementation of a system starting with test cases of an object, this is old, I at least have known these techniques since 1999, I will cite only one that defends this idea [Gelperin and Hetzel 1987]. Minimize the errors by focusing on the tests, and today as we are in the era of "JS frameworks", there is a semantics of confusing the implementation framework with work process framework with tools of griffe, which does not apply if they are not tested in the process by All, for all, not only by the 18-year-old project architect, this 18-year-old nowadays grant the role of software architect, senior software development positions to good early professionals, but with little experience, which For me 1996 was almost impossible to have a Jr. level in my classificatory parts of technical activities of the profession, I thought more imperative implementation than clear techniques, there have been many improvements, but today TDD - Test driven development can be put at high risk If you do not have experience in IT projects with software development with serious errors and also great achievements.
In many different techniques, used in the market and tested in the academic world, and professional can, I say by myself also, that the use of this technique is possible to reduce the complexity of software, increasing the maintainability of it. Failures are easily identified even in the development stage thanks to continuous feedback given to the programmer. The test units created allow you to more easily evaluate new defects that may have been inserted in the software facilitating the development of successive releases.


But a detail the professionals who do this are also with attributes of programmers, systems analysts know the world of implementation, this is my opinion for the success of TDD, adjust to lead to good results.


10.08.2015

One good choice use systems development with MDA - Model Driven Architecture

One good choice use systems development with MDA - Model Driven Architecture

The system development lifecycle process is a problem-solving process where requirements maybe considered problems occurring within a domain, systems that address the requirements may be considered solutions residing within an environment, and problem solving involves understanding a problem, solving the problem, and implementing the solution. 

One choice to solving problem of process of development is using MDA as good choice and with development tools integrate. Can implement with languages as Java, Python, C++.


Every system development lifecycle process involves the following types of lifecycle activities:
  • Requirements gathering activities to capture requirements that define what a system should do. This results in a requirements model that describes the problem and what a solution entails, and is said to occur from a conceptualization perspective since it focuses on the problem.
  • Analysis activities to understand the requirements. This results in an analysis model that describes how an abstract or implementation-independent solution satisfies what is specified by the requirements model, and is said to occur from a specification perspective since it focuses on the problem and solution.
  • Design activities to determine how a system will satisfy its requirements. This results in a design model that describes how a real or implementation-specific solution satisfies what is specified by the analysis model, and is said to occur from a specification perspective since it focuses on the problem and solution.
  • Implementation activities to build a system. This results in an implementation model that describes the actual solution or physical system that satisfies what is specified by the design model, and is said to occur from an implementation or realization perspective since focuses on the solution.
  • Testing activities to verify that a system satisfies its requirements.
  • Deployment activities to make the system available to its users.
Furthermore, there are many types of approaches or lifecycle models, bellow :
 1. Iterative,
 2. Waterfall,
 3. And so forth

Applying these activities, however every approach must confront the forces of change and complexity.

Figure 1 shows a conceptual view of the system development lifecycle process.

The domain and environment are shown as circles. The problem and solution are shown as solid-outline rectangles within the circles. The problem-solving process is shown as a solid-line path from the problem to the solution, and each perspective is shown as a dashed-line path from the solid-line path to the activities related to that perspective. Activities are shown as a shape with a straight top and bottom and convex arcs on the two sides, and models are shown as solid-outline rectangles.

When an activity uses a model as input, a dashed arrow is shown from the model to the activity. When an activity produces or updates a model as output, a dashed arrow is shown from the activity to the model. Because the requirements model represents the problem and the implementation model represents the solution, a dashed arrow is shown from each model to the item it represents...




5.19.2014

Como reforçar as atividades essenciais de um projeto ou de processo

Projetos de otimização de processos consistem em realizar o trabalho de ajustar um processo buscando sua melhoria. De acordo com Reint Jan Holterman, autor do white paper “Five Common Pitfalls in Process Optimization, And how to avoid them“, e de acordo com o livro do matemático Alkhaziri em meados do século 19 onde os grupos para empreender e ajustar produção faziam um esboço de um plano usando cálculos e figuras, que podemos dizer da fronteira do Norte da África ao Oriente Médio já utilizavam avançados métodos para  que os esforços de otimização tinham o objetivo de “ reforçar as atividades essenciais da empresa, produzindo melhores produtos e serviços, em um período mais curto de tempo, a um esforço ou custo mais baixo ”.  As atividades essenciais devem controlar a produção em a cada revisão estar melhor para objetivar menor esforço e alcance dos objetivos.

Qualquer planejamento a ser executado para a otimização de processos requer, então, que se possa produzir uma visão de futuro melhor para a execução de um processo olhando para a forma como ele acontece atualmente e seu histórico (lições aprendidas). Envolve atividades de modelagem, análise e redesenho do processo, e apesar de este ciclo já se constituir em uma prática comum em organizações que buscam a melhoria de processos através das práticas de BPM, estima-se que 60 a 70% de todos os processos de otimização não produzam resultados satisfatórios (leia mais aqui: http://esopsfables.wordpress.com/2012/02/29/why-process-improvement-projects-fail/).

Em seu white paper, Holterman e Alkhaziri exploram as cinco falhas mais comuns, responsáveis pelos problemas neste tipo de projeto:
1. Falta de clareza sobre onde começa e onde termina o trabalho
Muitos projetos são iniciados com uma declaração “vamos otimizar o processo tal”, mas não está claro para a equipe por onde começar e até onde se vai.
A falta de clareza sobre o início e fim do projeto leva a uma sequência de armadilhas que resultam em um processo desestruturado e interminável.
Em um projeto de otimização de processos é fundamental compreender a situação atual, o status quo do processo. Quem está envolvido, quais são as entradas e saídas, quais são os limites do escopo deste processo, qual é o tempo que o processo leva atualmente para ser executado, que exceções comumente levam a resultados diferentes e com que frequência acontecem, são questões iniciais que precisam ser feitas antes mesmo de se iniciar alguma ação de otimização.
Conhecer bem a situação atual do processo é tão importante quanto ter claro onde se quer chegar. É preciso que todos os participantes tenham uma visão clara de que melhoria deseja-se atingir com o projeto, se é um ganho de produtividade, de redução de tempo, de redução de custos, e que parâmetros definirão o atingimento do resultado esperado.
2. Usar indicadores (KPIs) inadequados
Os indicadores de performance (KPIs) são as referências que apontam a direção para a linha de chegada. Indicadores mal definidos levarão a equipe a sair do curso, já que apontam para a direção errada.

Sintomas comuns de um KPIs mal definido:
  • não está relacionado ou é impactado muito levianamente pelo processo de negócio;
  • pode gerar interpretações diferentes;
  • não é impactado apenas pelo processo, mas também por  fatores externos;
  • não está relacionado de alguma forma aos objetivos estratégicos da organização, de forma que mesmo que o processo obtenha alguma otimização, não há garantia que produzirá algum resultado melhorado para a empresa.
3. Falta de apoio do dono do processo e da alta gestão
O Patrono ou Dono do Processo (Processo Owner) é o responsável pelo desempenho do processo de negócio, e espera-se que seja o maior interessado no sucesso de um projeto de otimização, já que afetará diretamente os resultados do produto ou serviço gerado pelas atividades do processo de negócio. Consequentemente, sem um Dono do Processo que se importe em acompanhar o trabalho de otimização do seu processo (seja por falta de interesse ou de tempo para apoiar o trabalho), não se pode esperar grandes resultados do projeto.
Também o apoio da alta gestão da empresa ao projeto de otimização é essencial para o sucesso da iniciativa, de forma a garantir o envolvimento e a disponibilidade dos recursos necessários às ações de melhoria.
4. Não adotar as mudanças no processo
É da natureza humana apresentar resistência a mudanças – mudar envolve sair da zona de conforto, aquela em que conhecemos e controlamos como as coisas funcionam.
Por este motivo, comunicar bem e garantir que os envolvidos tenham tempo suficiente para compreender e aceitar as mudanças propostas é fundamental para o sucesso da implantação de otimizações no processo. As pessoas precisam entender por quê as mudanças estão sendo feitas para assimilar os benefícios a serem obtidos e efetivamente adotá-las.

5. Displicência na execução
Holterman e Alkhaziri aponta que em muitas organizações, os projetos de otimização acabam se perdendo em um perpétuo estudo e desgastante levantamento de informações, colecionando e analisando todo tipo de dado que se pode coletar acerca do processo na tentativa de representá-lo da forma mais apurada, às vezes envolvendo até mesmo coleta de informações de outros processos que nem estão diretamente relacionados ao escopo de otimização prevista no projeto. Mas dispender toda energia em gerar estatísticas complexas e painéis de monitoramento não trarão resultados práticos de otimização.
Controlar a execução, garantindo que as otimizações definidas sejam efetivamente executadas como planejadas, são um dos grandes desafios de um projeto de otimização e podem encontrar suporte na implementação do processo em um BPMS (Business Process Management System).
Uma notação deve ser como um "idioma" na nossa comunicação.