9. Team Collaboration Source Control / Centralized Repository Automatic Conflict Resolution History of Revisions Traceability Productivity
10. Deployment Process Version Control Version Compare/Merge Promotion Methodology (DevProd) “Promote” Change Quality Process
11. Testing Plan Plan Plan Prepare Tests Report Status Prepare Tests Report Status Prepare Tests Report Status Execute Tests Execute Tests Execute Tests
12. Testing Easily Automate Test cases Schedule Tests to run automatically Test the Genexus Objects Impact Analysis Productivity Evolve your tests as your KB evolves
13. From tools to action What are we building? What needs to get done? What should get done first? Who does what? Where in the process are we?
16. Development Life Cycle: Programming To-Do List within GX Access to centralized documentation Automatic status feedback Minimize Interruptions Take a Task DEV
17. Development Life Cycle:Collaborate Share the code Automatic status feedback Report effort Associate Gx-Objects with Work Items Do more with less DEV Complete DEV ‘
18. Development Life Cycle:Integrate Get latest version of the code into Test KB Impact Analysis (Gx + XPM) Know better DEV ‘ Build TEST
19. Development Life Cycle:Testing Know what to test Easy to create tests GxTest Impact Analysis Run tests automatically Test Productively Take a Test
20. TEST Development Life Cycle:Promotion Promote changes to another environment (version) Traceability Controlled Promotion Freeze/Merge QA
30. Thanks! Related Conferences / Labs XPM: eXtreme Project Management Monday 11:15 am. (Sebastian Jodal / Jean Pierre Valencia) XPM Lab Tuesday 2:30 pm GXTest Lab Tuesday 4:00 pm
Notes de l'éditeur
Goodmorningeveryone, forthose of youwhodon’tknow me mynameis Laura AguiarAnd I’m a project manager in GeneXus USA.TodayI’mgladtobepresentingthegeneXus Framework.And wewillstartthispresentationbytalkingabouttools…
When we choose our tools it is important to pick one that was designed for the specific purpose we are trying to achieve. But that is not enough, as it happens to the poor guy in the picture - even if the tool that was designed in general terms for the right purpose, it might still be still not be the right tool for the job.
And talking about the right tool for a job, we know Genexus is the right tool when it comes to develop software.We know it is the right tool because it allow us to accomplish our tasks – which is Develop Software - But also to do it in the way we want to do it – incrementally, productively, allowing us to focus in the business solution we are trying to implement and not in the technical details like the platform or the language we will deploy it to.
But, even if you have the best tool for the job, as sometimes if it does not have the right companions or the right support for it, we might not see it shine as much as it canIf you have the fastest guy alive running for your team
You would not give him these shoes – We would want to give him the tools to allow him to run as fast as he can
In the same way we have might have the fastest – or the most productive – development tool, but if we want it to run as fast as it can we need to surround it with it with the right set of toolsBecause software development is a process. Certain steps require specific tools – to collaborate, to test, etc - and we want all these tools to work in synch with Genexus so they don’t slow us down. And so we have the framework.
So, in the rest of this presentation let’s look at the framework tools and what they allow us to do,We will walk through the process by which we develop software using the framework tools.What are the framework characteristics
So, what are the framework tools?We have Genexus – which is our software development tool – We have GX Server that allow our team to collaborate while developing the softwareWe have GX Test that will help us during the testing phaseAnd we have XPM that not only allow us to manage our project but also integrates with the other tools in order to make us more productive and guide us through the software development cycle.Let’s see what are the main features and benefits of the tools in the framework – for this we will start directly with the Server as you are already probably familiar with Genexus.
Every development platform has tools that allow you to do source control and Genexus is no less. The server allows the team to share their code in a centralized repository. If two developers modified the same object at the same time, the server merges the changes automatically and when it is not possible it will provide the comparison tools so that the developer that caused the conflict can solve it in the easiest possible wayThe server also keeps a history of revisions that tell us what was changed, when and by whoWhen it comes to team collaboration, the server give us 2 main benefits, we have traceability and we have a huge impact in productivity.Once you use the server it becomes a natural part of the process to the point that you forget how hard all this was before, but if we think that centralizing the code and solving the conflicts used to be the job of a full-time member of the team, obviously when we give this task to the server we are freeing up at least one resource and thus our team is more productive.
The Server not only allows the team to collaborate, it is a version control tool so it also allows you to manage different versions and to merge changes between each of them. By mapping different versions to the different deployment environments – test, qa, uat & production – we have a controlled way to promote changes from one environment to the other.So now when requirements change, not only we have a development tool that allow us to easily introduce those changes, we also have a tool that help us manage the process by which we promote those changes to production.The server not only allow us to be more productive, it also makes it easier to have a quality process.
This brings us to the next tool in the framework, whose focus is testing.Testing is a big effort in the software development process, in some cases the testing phase is even longer than the development one. Still most of the case we keep testing by hand – which reminds me of the poor guy trying to cut the tree in the first slide.In many cases we don’t automate the tests because after we went through the process of plan, prepare the test, execute them and record the results, requirements change and now our test fail not because the program is wrong, but just because the test is outdated.And sometimes when things change frequently it is hard to keep up, so you think why bother?Wouldn’t it be great if were easier to automate the tests? Wouldn’t it be great if you knew ahead of time that the tests are outdated so you could save up the effort of running the wrong tests?
Well, actually you can have all that, because GXTest is a testing tool that was built for Genexus. GX Test not only allow us you automate tests cases and schedule to execute them automatically. But in only one you define test cases associated with the genexus objects and benefit from the knowledge stored in the KBGxTest has an equivalent of the impact analysis, so when things change some tests are automatically adapted – for a simple example if you rename some attributes in your transactions – and in other more complex cases – i.e. you removed some controls in a screen that you were testing before – GXTest impact analysis will let you know that the test needs to be updated.
So, we have the tools that allow us to program, collaborate, test and deploy. When changes happen we have a tool set that allow us to modify the programs, make sure nothing is broken and promote the changes to production.So we are in pretty good shapeBut… [CLICK] we still have many things to think aboutIn order to be productive during all this process, we need more than tools, we need to be able to plan and organize ourselves.We need to know what are the requirements are[CLICK] We need to organize the implementation of these requirements in tasks.[CLICK] We need to be able to prioritize these task, to be sure we have the most critical features done first[CLICK] We need to distribute the work and organize our resources[CLICK] And we always need to be able to know where we are in the process, because when things change we need to be able to make decisions on how to accommodate those changes, reprioritize, reassign resources, etc.
Basically we need to manage our project.And, there are many tools for project management. But XPM is the right tool to be part of the GeneXus framework.Because it was designed to support the way in which we developed software. It support an agile process by giving you the flexibility you need to adapt the plan as the project evolvesIt integrates with GeneXus and the GxServer – and in the future also with GxTest – in order to allow each team member to focus on what they need to do and not in the administrative parts of the process.I won’t go into more details of XPM because there is a presentation, right after this one, that focuses on XPM, but one thing that I wanted to highlight is that XPM focuses on productivity, the main goal of XPM was to avoid diluting the high productivity of GeneXus in an inefficient process. We designed a tool to allow us to be as productive in the whole development process as we are when we develop with Genexus,
So, we’ve described the tools of the framework, let’s walk through a development cycle to highlight some how these tools work together
We are focusing on the development cycle, so our story starts with the developer.The first thing that happens is that the developer will interact with XPM from within Genexus by looking at his work-list or to-do list.So without having to ask or log to some other application, the developer knows what he needs to focus in. Also thanks to XPM-Genexus integration, the developer gets access to the centralized documentation associated with the task. If the specification is clear he can start working – otherwise he can send the task back to specification and take the next task. When the developer takes a task, or sends a task back, the status of the task is updated automatically, so the manager knows that the task is taken care of.All this happens in the natural environment of the developer, so we minimize the interruptions and thus gain productivity.
Once the developer is done, again thanks to XPM-Genexus integration from within genexus the developer will mark the taken task as completed.At that point and with one operation many things happen The code is committed to the server and shared with the rest of the team The status of the task is updated as completed and the hours associated with the task are reported in XPM Finally, thanks to XPM’s Server extension, the Genexus objects are associated with the task (this is a very powerful association and we will come back to this point later).So this is one operation for the user, but a lot of things happened automatically. We are not asking the user to stop what he is doing to report administrative information – XPM’s gx extension even keeps track of the hours to be reported – we let the developer focus on developing and XPM and the Server do the rest of the work.[CLICK]We are being more productive because we are doing more with less
After all the developers produced enough functionality, the tester will start testing the code. And the tester works in a test-kb. So the first thing that happens here is that the test-environment is updated with the latest version of the code which is done by doing an update in the GXServer.When the integration tester does an update, he gets to see the objects that will be updated from the Gxserver. From XPM he also the information of features impacted by the programmers– this is important because it is possible that some features were affected even if nobody worked on them directly, just because they share some object with the features that were updated in this build.When we combine the information from the modified objects from the Server, and the impacted features from XPM we have better information, which allow us to miss less things and again be more productive.
From the previous step the tester knows exactly what needs to be tested.Knowing exactly what to test is important as it narrows our focus.We might have already automatic tests for that, or we might need to create them. If we already have them, we know right away if we need to update them thanks to the Impact Analysis.Once the tests are in place they can run automatically, thus we test more productively.
Once the tester is done with the tests, if tests are passed the code can be promoted to the next environment – which is done by merging changes in the test KB into the QA KB.And we get to freeze up versions when they are stable enough.Basically we have a controlled – and traceable – promotion process that prevent us from introducing mistakes.
We will repeat this process for each of the different environments that we have between development and production.Each of these environments will be a frozen version in the server, that might have a branch open for fixes needed in that environment. In case fixes are introduced in an environment branch, the same version-merge feature help you promoting those changes up in the chain till the current development version.
With the server we have way to promote code from development to production, but once we add XPM in the mix we have a way to keep track of the promotion of functionality.Which functionality is in development, what is ready to test? What is in QA? What was deployed already? But at a level of tasks and features, which is the level that our customer would care to know.In the last two steps there will be more things done automatically by XPM once we add more features to the server integration and we integrate with GXTest, so maybe in future presentations of the framework we can save a couple of slides.
We’ve seen a walk through of the framework and how the different tools of the framework help us in each step of the cycle. But why do we call this “the framework” and not “the genexus suite” or “our tool set”….We call it the framework because these tools were made for each other and share certain characteristics that make that when together these tools become one entity
They all believe in automation.Automation as a mean to achieve productivity – when we let a machine do the automatic tasks we make it faster, we make it less error-prone, and we free up the time of our team members to focus on what adds value. There is some productivity gain that is obvious as the machine does repetitive tasks faster, but there is also an improve productivity that is gained due to higher satisfaction of the people that are doing a more meaningful job.
These tools were designed in order to support an incremental approach to software development.The ability of Genexus to introduce changes without losing productivity is probably one of the reasons why you chose it as your development tool, Now you have this power extended to the rest of the process.
All these tools put a value in knowledgeGeneXus lets you develop at a higher level of abstraction – that is why we have a knowledge base and not source code.You can benefit from that knowledge when programming from Genexus but now also when testing, because GXTest builds upon that knowledge. GXTest allow us to add validation criteria, or acceptance tests to the business rules that we have in Genexus.Finally XPM links the Genexus objects with the application specifications and requirements, this allow us to go from the programming world – of objects, databases, datasets, etc – to the business problems we are solving – where we have requirements, services. When this is put together with GeneXus Cross-Reference, we can know what functionalities might be affected by changes in one object because it is either directly or indirectly related with other functionality.This adds another level to the knowledge we have in the KB.We care about knowledge because knowledge is power and from knowledge we can automate more and thus be even more productive
So because of these shared characteristics and the fact that they build upon the strength of the otherWhen put together these tools become more than a Programming tool, a collaboration tool, a management tool and a testing tool, we achieve synergy because the total is more than the sum of the parts.When together we have a framework that supports our development process, while increasing our knowledge and our productivityWhen we surround genexus with the right companions, not only we are not slowed down
Instead we allow Genexus – and therefore us – to be the best that we can be
