Interaction Design is one of the many facets of User Experience Design. The Encyclopedia of Interaction Design defines it as “shaping digital things for people’s use.” It’s a complex and wide ranging field that covers nearly all aspects of cognition, emotion, and behavior.
In my last post, I showed how you could use mocking frameworks and dependency injection to create unit tests for methods that query a database using Entity Framework. In this post, I will show how you can use the same techniques to test data access code that will insert, update or delete a record from the database.
Recently, the data access technology that we have relied on for most of our projects is Entity Framework. Entity Framework is an excellent tool that makes it easy to work with a database using the .NET code that we are most familiar with. However, out of the box, Entity Framework does little to help support automated unit testing. Specifically, the DbContext is not interface-based and does not provide a clean way to support mocks. This makes it difficult to write a unit test that doesn’t require database access, which would result in slow and error-prone tests.
In my ten years of working within the IT industry, managing requirements has never been a clear-cut task, especially when the triple constraints – Scope, Cost and Time – always change due to business conditions. (For more information on the triple constraints, please refer to the latest version of the PMBOK guide.) But suffice it to say, managing requirements is challenging because of their ambiguity, which happens when they have not been communicated clearly to the appropriate stakeholders. To make matters even more challenging, ambiguity further propagates depending on how the various stakeholders interpret those requirements and document them. As this infamous comic cleverly illustrates:
Business analysts have a potentially long list of responsibilities and deliverables. Finding the time within a project to include all of the best practices can often be a challenge, and some important techniques, deliverables, and responsibilities are often neglected or ignored simply because there isn’t enough time available. This includes such things as requirements traceability, stakeholder analysis, reports analysis, impact assessments, and handoffs to other project team members. These are often sacrificed for the sake of creating the perfect requirements document, use cases, or diagrams and models. I’d like to focus this article on one of these often neglected work items – handoffs to other project team members.
We all grew up hearing stories. Whether it was a fairytale, a Disney version or a family treasure, stories have always been used to communicate, teach and share information. Throughout time, people have learned by remembering the moral of the story, the important lesson, a takeaway. Just think about the age old tale of the tortoise and the hare. The moral of the story has stood the test of time and is just as relevant today in 2014 as it was many years ago. In fact, all someone has to do is mention the tortoise and the hare, and you instantly can relate to the topic.
Classic project management theory states that projects have three constraints: cost, time and scope. In some environments, there are additional constraints; for example, healthcare projects include an additional patient safety constraint which is considered paramount. In general, every project environment is unique as factors such as quality, risk, vendor relations, and so on are taken into account.
In my last post, I mentioned that one problem with my earlier unit tests was their dependency on database access. Having my tests directly dependent on the database created slow-running tests and tests that were prone to failure as the database changed. Over the course of this post, I’m going to demonstrate some of the techniques I have learned that provide the ability to decouple a set of code from using direct database access. Note that the examples are in C#; however, the principles apply to any object-oriented language with a unit testing framework.
The Object Management Group (OMG) is defining a new standard for decision modeling: Decision Model and Notation (DMN). If you aren't familiar with the OMG, they are an organization whose goal is to develop standards by reviewing and refining commonalities between existing models and notation.
In spite of diligent planning, documentation, and proper process adherence in software development, occurrences of defects are inevitable. In today’s cutting edge competition, it is important to make conscious efforts to control and minimize these defects by using techniques to allow in-process quality monitoring and control. Defect Prediction using Rayleigh’s distribution curve is one such method that helps us to understand the density of the defects and their distribution across project phases as a project progresses.