A recent Methods & Tools survey wanted to know if organizations were using NoSQL databases (MongoDB, Couchbase, etc) ? The results show that 27% percent of the participants have some applications in production based on NoSQL databases. Read the rest of this entry »
The software development magazine Methods & Tools has recently asked its readers if their organization were hosting their software applications on a cloud infrastructure. Read the rest of this entry »
Many people consider that software architecture is a burden for agile software development and that a “good” design will naturally emerge as code is produced during each Scrum sprint. This however rarely the case and as in many other activities, you have to find the right balance between doing enough but not too much software architecture. In the article, “A Risk-Driven Model for Agile Software Architecture“, George Fairbanks, the author of the book “Just Enough Software Architecture – A Risk-Driven Approach“, explains how to achieve this balance.
The main rule is that the effort you spend on designing your software architecture should be commensurate with the risks faced by your software development project. The article examines how risk reduction is central to all engineering disciplines. It explains how to choose techniques to reduce risks and show how you can balance planned design with evolutionary design during agile software development projects.
Certifications have become an important part of the life of software development professionals. If there is some aims by hiring organizations to try to assess the capacity of their future employees, certification is also a lucrative market for training companies and professional organizations that
sell, sorry provide the certifications. The situation is very competitive in the project management market where besides the traditional PMP certification provided by the Project Management Institute, there has been the increased adoption of agile project management certification, mainly the ScrumMaster official titles provided by either the Scrum Alliance or Scrum.org. This is so true that the PMI has now developed its own Agile Project Management certification. Certifications are also present in another number of software development areas. According to the Software Testing Magazine, the International Software Testing Qualifications Board (ISTQB) is the clear leader in the field of software testing certifications, with only few competitors that act more locally. In the area of software requirements management and business analysis certification, the International Institute of Business Analysis (IIBA) is the main professional and certification organization. There are however alternative certification scheme provided by organizations like the International Requirements Engineering Board, the British Computer Society (BCS) or the Object Management Group (OMG) which specialize in UML-based analysis certifications.
Issues with testability boil down to our inability to write tests or the excess trouble we have to go through to get it done. The article “Guidelines for Java Testable Design” is excerpted from the Unit Testing in Java book by Lasse Koskela. In this extract shares a set of dos and don’ts for testable design and recommends to avoid complex private methods, static methods, logic in constructors and to favor composition over inheritance. He also suggests to treat the new keyword with care because it essentially hardcodes an implementation we cannot substitute.
The opening keynote of the Google Test Automation Conference 2011 was presented by Alberto Savoia, Director of Engineering at Google who discusses the proposition that software testing is dead. He suggest that software testers should shift their mindset from “Are we building it right?” to “Are we building the right it?”. The idea that it is more important to have a context where the right software product is developed, instead of setting quality procedures that verify the product at the end.
Use cases, user stories, or backlog items already define broadly the scope of a project. Many teams consider requirements as something provided by the business users, product owners or customers. Asking business users to provide the scope is effectively relying on someone who has no experience designing software solutions to give us a high level solution design. This article explains how project teams can work together with business users to come up with the right scope. To reach this goal, you need to start with business goals, and not with user stories, and derive the scope from that.