Monday, November 20, 2017
Sunday, November 19, 2017
Cloud service models (recap)
Friday, November 10, 2017
iContract for Java...
- Many programming languages have facilities to make assertions
- iContract in Java is one such.
- iContract is a preprocessor for Java. To use it, you first process your Java code with iContract, producing a set of decorated Java files. Then you compile the decorated Java code as usual with the Java compiler.
- All iContract directives in Java code reside in class and method comments, just like Javadoc directives. In this way, iContract ensures complete backwards-compatibility with existing Java code, and you can always directly compile your Java code without the iContract assertions.
- In a typical program lifecycle, you would move your system from a development environment into a test environment, then into a production environment. In the development environment, you would instrument your code with iContract assertions and run it. That way you can catch newly introduced bugs early on. In the test environment you may still want to keep the bulk of the assertions enabled, but you should take them out of performance-critical classes. Sometimes it even makes sense to keep some assertions enabled in a production environment, but only in classes that definitely are in no way critical to your system's performance. iContract allows you to explicitly select the classes that you want to instrument with assertions.
Invariant with iContract
Source:
Agile Product Quality
Ensuring Product Quality in Agile
In his seminal book “Out of Crisis”, Edward Deming, the Quality Guru, summarized the Quality Management philosophy in 14 points. One of which is below:
Talking about inspection, he says “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place”.
The bottom line is, inspections / reviews are an act too late into the product lifecycle, since they are done after the product reaches certain maturity. Therefore at best they can be a catalyst, but not by themselves assure quality. Not so different in this new world of Agile Development as well where inspections, reviews or another mechanism are all considered extrinsic to product development and so cannot completely assure product quality. Product quality it appears is built into the product.
Product development teams take charge of product quality assurance by adopting certain core engineering practices, thereby delivering Outcomes, not merely Outputs. The understanding being the quality of a product is intrinsic and is built into the product. Extending the logic, therefore, built-in quality practices will alone be able to improve product quality.
Some of the key aspects of Product Quality in the Agile context and how they are achieved are discussed below.
1. Requirements Traceability: Requirements traceability is intrinsic to Agile framework. There is a natural and strong hierarchy if we may call so, of user needs from Epic, Feature to User Story. And from there to DoD and further traceability to acceptance tests.
2. Architectural Runway: In Agile, architecture is done incrementally starting with an emergent design, which can be improved as sprints progress. This incremental approach to architecture instead of big-bang results in a model that is robust, yet is flexible to future changes.
3. Verification , Validation: Backlog grooming, Release Planning, Sprint planning, Daily stand ups, Product demos, and retrospective meetings – all these key Agile ceremonies are done very frequently and iteratively in Agile and can be seen as Verification and Validation activities. Backlog grooming and sprint planning vigorously allow for debate on the needs, technical feasibility, prioritization, etc. The very fact that there is intense discussion around these topics and an AskàReviewàFollow-up loop ensures there is no ambiguity on the needs. Stand ups, retrospectives, and the level of communication among team members ensures the solutions, approach, plans etc. are continuously discussed & verified, and adapted. Product Demo ensures validation happens.
4. TDD and Refactoring: Only so much of code is written as to pass the written test case. This test-first approach guarantees the code has fewer bugs, is relatively clean, and most importantly, results in a code that is easy to maintain, flexible and can be easily extended
5. Pair programming: makes sure that there is live critique – reflect, correct, and progress on the code. This leads to increased code discipline, better code and collective code ownership, all of which benefits team cohesiveness.
6. Continuous Integration: Continuous integration ensures build and integration errors are detected early, easy to find and fix bugs, accelerates the build process, and results in full code visibility.
7. Continuous Delivery: Ensures enhancements, bug fixes, are rapidly and reliably pushed to production for a seamless experience to customers.
8. Definition of Done: Definition being binary – either achieved or not achieved, clearly removes ambiguity of what has and has not been achieved at Story, Sprint, Release levels.
9. Acceptance Criteria: Similar to DoD, Acceptance Criteria unambiguously gives the development team clarity on what it would take for the user story to be accepted as complete. Moreover, acceptance criteria can be easily translated to manual or automated test cases.
10. Continuous Improvement: Sprint on Sprint, Agile teams reflect and adapt their practices to suit and better their performance. Agile retrospectives in this sense, by design, allow and promote continuous improvement.
Product quality in Agile is a combined ownership, fostered by collaborative and proactive behaviors of team members.
In his seminal book “Out of Crisis”, Edward Deming, the Quality Guru, summarized the Quality Management philosophy in 14 points. One of which is below:
Talking about inspection, he says “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place”.
The bottom line is, inspections / reviews are an act too late into the product lifecycle, since they are done after the product reaches certain maturity. Therefore at best they can be a catalyst, but not by themselves assure quality. Not so different in this new world of Agile Development as well where inspections, reviews or another mechanism are all considered extrinsic to product development and so cannot completely assure product quality. Product quality it appears is built into the product.
Product development teams take charge of product quality assurance by adopting certain core engineering practices, thereby delivering Outcomes, not merely Outputs. The understanding being the quality of a product is intrinsic and is built into the product. Extending the logic, therefore, built-in quality practices will alone be able to improve product quality.
Some of the key aspects of Product Quality in the Agile context and how they are achieved are discussed below.
1. Requirements Traceability: Requirements traceability is intrinsic to Agile framework. There is a natural and strong hierarchy if we may call so, of user needs from Epic, Feature to User Story. And from there to DoD and further traceability to acceptance tests.
2. Architectural Runway: In Agile, architecture is done incrementally starting with an emergent design, which can be improved as sprints progress. This incremental approach to architecture instead of big-bang results in a model that is robust, yet is flexible to future changes.
3. Verification , Validation: Backlog grooming, Release Planning, Sprint planning, Daily stand ups, Product demos, and retrospective meetings – all these key Agile ceremonies are done very frequently and iteratively in Agile and can be seen as Verification and Validation activities. Backlog grooming and sprint planning vigorously allow for debate on the needs, technical feasibility, prioritization, etc. The very fact that there is intense discussion around these topics and an AskàReviewàFollow-up loop ensures there is no ambiguity on the needs. Stand ups, retrospectives, and the level of communication among team members ensures the solutions, approach, plans etc. are continuously discussed & verified, and adapted. Product Demo ensures validation happens.
4. TDD and Refactoring: Only so much of code is written as to pass the written test case. This test-first approach guarantees the code has fewer bugs, is relatively clean, and most importantly, results in a code that is easy to maintain, flexible and can be easily extended
5. Pair programming: makes sure that there is live critique – reflect, correct, and progress on the code. This leads to increased code discipline, better code and collective code ownership, all of which benefits team cohesiveness.
6. Continuous Integration: Continuous integration ensures build and integration errors are detected early, easy to find and fix bugs, accelerates the build process, and results in full code visibility.
7. Continuous Delivery: Ensures enhancements, bug fixes, are rapidly and reliably pushed to production for a seamless experience to customers.
8. Definition of Done: Definition being binary – either achieved or not achieved, clearly removes ambiguity of what has and has not been achieved at Story, Sprint, Release levels.
9. Acceptance Criteria: Similar to DoD, Acceptance Criteria unambiguously gives the development team clarity on what it would take for the user story to be accepted as complete. Moreover, acceptance criteria can be easily translated to manual or automated test cases.
10. Continuous Improvement: Sprint on Sprint, Agile teams reflect and adapt their practices to suit and better their performance. Agile retrospectives in this sense, by design, allow and promote continuous improvement.
Product quality in Agile is a combined ownership, fostered by collaborative and proactive behaviors of team members.
Contract-First Design OR Design by Contract (DbC)
- "DbC Is an approach for designing software.
- It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, post conditions and invariants. These specs are referred to as Contracts…
- The Design by Contract (DBC) software development technique ensures high-quality software by guaranteeing that every component of a system lives up to its expectations.
- Bertrand Meyer developed DBC as part of his Eiffel programming language."
1. Preconditions
2. Postconditions
3. Class invariants
- Central to DBC is the notion of an assertion -- a Boolean expression about the state of a software system.
- At runtime we evaluate the assertions at specific checkpoints during the system's execution.
- n a valid software system, all assertions evaluate to true. In other words, if any assertion evaluates to false, we consider the software system invalid or broken.
- DBC's central notion somewhat relates to the #assert macro in C and C++
Extreme manufacturing (XM)
"The name was coined in 2012
by Joe Justice, founder of Wikispeed, and Marcin Jakubowski, founder of Open
Source Ecology, as a take-off of the name extreme programming (XP), a software
development methodology."
"eXtreme Manufacturing (XM) is an iterative and incremental
framework for manufacturing improvement and new product development that was
inspired by the software development methodology Scrum and the systematic
waste-elimination (lean) production scheduling system Kanban"
The 10 core principles of XM are:
1. Optimize for change
2. OO, Modular Architecture
3. TDD
4. Contract-First Design
5. Design iteration
6. Agile h/w Design Patterns
7. CI Development
8. Continuously deployed development
9. Scaling patterns
10. Partner patterns
Subscribe to:
Posts (Atom)
SQL Essential Training - LinkedIn
Datum - piece of information Data is plural of datum. Data are piece of information - text, images or video. Database - collection of data. ...
-
Definition ITIL is a " framework of best practice approaches intended to facilitate the delivery of high quality IT services" . It... -
High Maturity in CMMI for Development - Part 1 Reference: http://www.connect2hcb.com/tiki-index.php The high maturity concept in CMMI ...