Enterprise Architect version 15.2



My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

doug rosenberg

doug rosenberg

doug rosenberg

Parallel Agile, Inc. (Founder, Chief Technology Officer) - formerly ICONIX (CEO)
After running ICONIX for 35 years and writing 7 books on UML, use cases, and agile software development, Doug discovered a new way to improve productivity by leveragng parallel development, and founded Parallel Agile (www.parallelagile.com) in 2018 after 4 years of test projects at the USC Center for Software and Systems Engineering, where he's been working with Prof. Barry Boehm.   A new book "Parallel Agile - Faster Delivery, Fewer Defects, Lower Cost" is mostly written and will be released during 2019.   We're also developing a Parallel Agile Add-In for Enterprise Architect and are available for training and consulting.  
In his previous lifetime...
Doug Rosenberg founded ICONIX in his living room in 1984 and began training companies in object-oriented analysis and design around 1990. ICONIX specializes in JumpStart training for UML and SysML, and offers both onsite and open-enrollment courses.
Doug developed a Unified Booch/Rumbaugh/Jacobson approach to modeling in 1993, several years before the advent of UML, and began writing books around 1995. Design Driven Testing is his 6th book on software engineering. He’s also authored numerous multimedia tutorials (including Enterprise Architect for Power Users) and several eBooks, including Embedded Systems Development with SysML.
Doug has spent the last few years doing "deep dive" consulting into cutting-edge technology including cross-platform mobile app development, REST APIs, and NoSQL databases, and gaining first-hand experience on some "hardcore agile" projects of varying sizes.  He's also been working with dozens of graduate students at the University of Southern California Center for Systems and Software Engineering (USC CSSE), managing Directed Research projects and developing/piloting the Parallel Agile process.


Your organization is committed to Agile, Scrum and TDD. That’s not going to change.  But somehow things aren’t going as smoothly as you’d like. Your project is on the “underplanned” end of the spectrum and you feel like everything could be working more smoothly.

If I’ve just described your current situation, then this article might be for you.  The Resilient Agile (RA) process combines Test Driven Development with Design Driven Testing, resulting in improved coverage for both unit and acceptance testing, and helps you plan your sprints better by introducing visual modeling of user stories, epics, and tasks.  

RA is agile on the project management side, and scenario driven on the technical side.  Enterprise Architect can help you to build, manage and enhance your Agile development projects.  This article show shows how Enterprise Architect can be used to implement Resilient Agile in your project.


Resilient Agile interfaces Design Driven Testing to Test Driven Development -- and it's only supported by Enterprise Architect


Resilient Agile is balanced between planning and feedback

The agile movement properly recognizes the value of getting to code early and not spending years on “Big Design Up Front” without demonstrating executable software early in the lifecycle. Agilists are correct in believing that a great deal of knowledge will be gained about system requirements by putting live software in the hands of users early. However, agile development as currently practiced across much of the industry has removed too much engineering from software engineering.

Agile/scrum and kanban put the focus on project management rather than engineering. Engineering tends to be left to the discretion of the developers, and there is an active mindset of “code first, refactor later” as opposed to systematic exploration of requirements and designs. Agile in practice is often used as an excuse for not doing architecture, not doing engineering and avoiding thinking about rainy day scenarios, leading to buggy, fragile (non-resilient) software. There is a general mindset on agile projects of achieving quality by testing rather than achieving quality by design. This mindset very often tends to be overly-focused on unit testing because acceptance testing requires that rainy-day scenarios be fully modeled and accounted for.

RA puts the engineering back but still fits with scrum and TDD

Complicating the problem, basic software engineering skills like developing quality use case models that fully explore sunny/rainy day behavior, how to properly decompose a use case into models, views, and controllers (MVC) and how to model the problem domain as a set of conceptual objects are often not taught adequately at the university level.Resilient Agile (RA) is an attempt to put the necessary engineering back into software development without losing the “get to code early” focus that agile gets right. RA is based on a time-tested method (ICONIX/DDT) of developing an initial problem domain model, then decomposing a system into collaborating use cases and elaborating each use case by doing a conceptual MVC decomposition.


ICONIX Resilient Agile - A Better Agile Methodology


Friday, 22 July 2011 00:00

Design Driven Testing for Systems

Design Driven Testing (DDT) for software was first outlined in the book Use Case Driven Object Modeling with UML: Theory and Practice (by Doug Rosenberg and Matt Stephens), and then described in detail in Design Driven Testing: Test Smarter, Not Harder by the same authors.

DDT is a highly methodical approach to testing, allowing you to know when you’ve finished – i.e. when you’ve written enough tests to cover the design and the requirements. It helps you to “zoom in” and write algorithmic tests to cover intensive or mission‐critical sections of code, and to know when it’s safe to “zoom out” and write fewer tests for boilerplate or less critical code.
In this Article, Doug extends the concept of DDT for hardware/software systems, allowing SysML‐based designs to be tested in a highly rigorous, systematic way. It’s still Design Driven Testing, but now the design elements that need to be tested include all of the “four pillars of SysML”, whereas DDT for software focuses on testing behavior.

DDT Systems

The attached presentation, from the recent ESRI Developer Summit, presents the design of the hotel mapping application, and discusses bugs that were detected and fixed before product release following the DDT approach.

ICONIX has collaborated with Sparx Systems to produce a uniquely powerful set of capabilities for driving testing from Enterprise Architect UML and SysML models.    By combining the functionality of Sparx's structured scenario editor and that of the Agile/ICONIX add-in, it's now possible to automatically generate test cases at multiple levels of abstraction.   These include two levels of developer testing, including automatic generation of unit test code for JUnit, NUnit and FlexUnit, and two levels of acceptance/QA testing, including generation of test cases for Requirements, and scenario-based testing using a "use case thread expander" which automatically generates test scripts covering all permutations of sunny-day/rainy-day scenarios.

We've published our approach in a book called Design Driven Testing (DDT), which I co-authored with Matt Stephens, and we proved our concepts on a real, commercially available product, an interactive mapping system built with ESRI's ArcGIS Server geospatial engine, and in commercial use on a travel website, VResorts.com.

The attached presentation, from the recent ESRI Developer Summit, presents the design of the hotel mapping application, and discusses bugs that were detected and fixed before product release following the DDT approach.

Here is Chapter 7 of Design Driven Testing. This chapter focuses on Acceptance Testing, and leverages Enterprise Architect's Structured Scenario editor heavily to accomplish something we call "use case thread expansion" where all of the sunny day / rainy day permutations of a use case are expanded out into a complete set of tests.

In "test driven" approaches to development, unit testing often gets most of the attention.  However, unit testing is generally most useful in discovering "errors of Commission" (more poetically, "whoops, I coded that wrong").  Unit testing is of much less help in discovering "errors of Omission" (more poetically, "whoops, I didn't think of that").  In general errors of Omission are much trickier to detect, and there is very little automated support for detecting them.  We worked very closely with the development team at Sparx as they developed the "use case thread expander", and it brings a very unique and useful capability to the industry.

As you read this chapter, make sure you don't miss the discussion at the end of the chapter called "And the moral of the story is..." where we describe some actual "errors of Omission" that were caught and fixed before the release of our mapping software using these acceptance testing techniques, and how fixing these errors improved the user experience.

In today's agile universe, we often hear about "test-driven" approaches to development (TDD). TDD emphasizes unit testing to such an extent that in many companies, regression testing frameworks like JUnit have largely replaced upfront design. Design Driven Testing makes the case that skipping design in favor of unit testing is not only backwards, but also Too Damn Difficult. We thought the best way to prove it was by designing and testing a real production application...

My new book Design Driven Testing (co-authored with Matt Stephens) addresses both unit testing by developers and acceptance testing, performed by an independent QA organization.  Somewhat uniquely, the book features a real production system as it's teaching example.  A worldwide interactive hotel mapping (GIS) application, designed with ICONIX Process,  built using Java, Flex, and the ESRI ArcGIS Server mapping software, that we call "mapplet 2.0", which is in production use on the VResorts.com travel website.

This sample chapter presents the full ICONIX Process design of the mapplet project, starting from functional requirements and use cases, all the way down to reverse engineered class diagrams from the final code.   One of the unique virtues of using a production example as a teaching example in a book like DDT, is that it's possible for readers to look at the use cases in the attached chapter, and then compare them to the released software as deployed on VResorts.com.  

Next month I'll be posting another sample chapter from the DDT book which describes the scenario testing we did before releasing the software and some very real improvements that were made to the usability of the final product as a result.  If you'd like to work through the design and testing of mapplet 2.0 with me, in person, our Hands On ICONIX Process open enrollment classes give you exactly that opportunity.   In addition to 1 day modules on Business Process Modeling, Service Oriented Architectures, and Embedded Systems Development using SysML, we'll be working through this example for 2 of the 5 day lab sessions.

Also, between now and the end of the year, anyone who orders Design Driven Testing directly from ICONIX will get a free copy of Agile Development with ICONIX Process.

This article (which actually represents the third incarnation of the ICONIX Business Modeling Roadmap), leverages two new capabilities from Sparx Systems, now available in Enterprise Architect. These are the Structured Scenario Editor and the Business Rule Composer. The article describes how these two quantum leaps in technology combine synergistically to enable a new process by combining business process modeling with behavioral code generation for business rules.

Tuesday, 28 September 2010 00:00

eBook: Modeling Service Oriented Architectures

Presents a practical approach to modeling Service-Oriented Architecture solutions from concept to code. Topics include: generating web service interfaces from visual models, BPEL engineering and behavioral code generation.

This E-book presents a practical approach to modeling Service-Oriented Architecture solutions from concept to code. The author helps us to understand key SOA concepts and demystifies the "acronym soup" surrounding service-oriented development. Using an illustrated example, the reader is guided through the 'hands-on' ICONIX Process Roadmap for Service-Oriented Architecture. Each step of the roadmap is brought to life using Enterprise Architect Business and Software Engineering edition to derive concrete deliverables from visual models.

Topics include: business rules identification, generating web service interfaces from visual models, BPEL engineering and behavioral code generation.

The eBook is accompanied by an "SOA Project Template" EA model.

ICONIX SOA Project Overview

The SOA Project Template model contains our SOA Roadmap, a pre-fabricated project package structure, and a Car Rental example which includes:

  • a Domain Model
  • a WSDL package
  • a BPMN model
  • example of BPEL code generation from the BPMN model
  • a Rule Flow diagram containing Rule Tasks for use with the Business Rule Composer and Behavioral Code Generation

ICONIX now offers JumpStart training on the process described in this eBook, details are available at http://www.iconixsw.com/soajumpstart.html

ICONIX Process Roadmap for Service Oriented Architectures


Friday, 22 March 2013 22:15

Four Principles of Agile Triage

There’s an epidemic of bad software floating around these days.  Chances are you’ve encountered buggy and/or unnecessarily hard to use software recently. 

This epidemic isn’t really surprising, especially if you’ve read the books I’ve written with Matt Stephens: Design Driven Testing or Extreme Programming Refactored or Agile Development with ICONIX Process.  There’s a bunch of agile development shops out there underspecifying their software and (as a result) testing it inadequately, so that you and I can have the privilege of debugging it for them and putting new user stories onto their backlog.

Imagine for a moment that you’re working at a company where the agile development process has gone off the rails and there is a train wreck. There’s a lot of smoke from the burndown charts burning up.  Bodies are strewn all around, there are broken bones and people are bleeding everywhere. Some parts of your code are savable, and some have to be thrown away. You need to triage the situation and do damage control.  Here are some guiding principles for your triage effort:

1.     You can’t unit test what you forgot to remember.

2.     You can't do scenario testing without modeling scenarios

3.     You can't do requirement testing without modeling requirements

4.     Excessive timeboxing results in shoddy workmanship

 Embedded Systems Development using SysML is not just an overview of the SysML modeling notation - it is a practical guide for systems engineers! The book provides a well defined approach to systems development, and applies it to a detailed example Audio Player system.

In this e-book, author Doug Rosenberg introduces a new roadmap for embedded systems development – ICONIX Process for Embedded Systems.

Each step of the process roadmap is clearly explained, and illustrated by example, using Sam Mancarella's Audio Player model constructed in the Systems Engineering edition of Enterprise Architect.

Topics covered in the e-book include SysML modeling concepts such as requirements, block definition, system behaviour, parametrics, state charts and software implementation, as well as advanced capabilities of Enterprise Architect's Systems Engineering edition including built-in simulation, along with state-machine-driven code generation in VHDL, Verilog, and System C.

Friday, 05 February 2010 20:41

eBook: 20 Terabytes A Night

Describes experiences and lessons-learned from the Large Synoptic Survey Telescope (LSST) project. The sheer size and complex nature of LSST, bring a unique set of challenges and a massive software modeling endeavor. UML and ICONIX process are critically important in such an undertaking. Includes an in-depth discussion of tailoring ICONIX Process to support algorithmically-intensive development.

In its first month of operation, the LSST will see more of the Universe than all previous telescopes
combined. Its rapid‐fire, 3 billion pixel digital camera will open a movie‐like window on objects that
change or move; its superb images will enable mapping the cosmos in 3D as never before.
Surveying the entire sky every few days, LSST will provide data in real time to both astronomers and
the public.

The Data Management (DM) part of the LSST software is a beast of a project. LSST will deal with
unprecedented data volumes. The telescope’s camera will produce a stream of individual images
that are each 3.2 billion pixels, with a new image coming along every couple of minutes.
In essence, the LSST sky survey will produce a 10 year “sky movie”.

For LSST Data Management, a good strategy is to make extensive use of rapid prototyping (in this
case algorithm development via prototyping) in addition to UML modeling. So a two‐pronged
strategy of prototyping and modeling has been underway on LSST for a few years now.

A further complication in modeling LSST’s DM software is that the development is being done in
multiple, independent, geographically distributed research organizations—places like Princeton,
Stanford, University of Washington and Caltech, among others. This places some significant
requirements on the modeling tools that are used by the project.



Page 2 of 4