Month: February 2018

Erinnerungen an vergangene Arbeit

Ich hatte meine Arbeit mit MBD beginnen 25 jahr wenige mit General Motors; für deise Autoindustrie.  Auf das Zeit MBD war neu und ehrlich gesagt, waren die Werkzeuge weniger ausgereift.  Leute hatte eine Bedürfnis für Verbesserungen aber alles war nicht klar wie zu vorgangen.  Es war die “Wild West.”

Über Zeit,  Best Practices entwickeln von Industrie Erfahrung.  Durch den frühen 2000er Jahren moderne Prozesse waren vorhanden.

Dieser Zeit für die Medizinprodukteindustrie erinnert mich dieser Zeit Autoindustrie. (Aber mit die Werkzeuge ausgereift.)

Alt probleme, alt frage, neu antworten

Die Medizinprodukteindustrie ist die gleiche Probleme sehen das Autoindustrie vor 20 Jahr; Zusätzlich zu, dass sie konfrontiert sind regulatorische Fragen.  Die Medizinprodukteindustrie ist, nur natralich, vorsichtig wann neue Prozesse übernehmen.  because of this “use cases” from other industries are required for validation of the process.

• Power generation
• Nuclear power
• Automotive
• Aerospace

Letzte Worte

Drie ding: Erste für Alles das klar sind im meine im Deutsche schreiben; habe ich mein Mitarbeiter zu danken. Alles das sind nicht klar ich meine Entschuldigung gibt.  Zweite, München ist ein Stadt mit schöne Gebäude und wunderbare Menschen.  Letzt ich habe learnen zu essen das Brezeln für Frühstück und das war sehr gut.

If in the heart of agile development can be seen in the concepts of quick iterations, leveraging test points for quality assurance coupled to a close team-based collaboration then Model-Based Design are the veins and blood that compose the body of your work.

Agile is a concept and
a process; how that concept is implemented is up to the development team.

If we review the key concepts behind Model-Based Design and Agile Development then the mapping between is obvious.

Use models for architectural decomposition:  Models are used to break down large problems into smaller components.  These smaller components can easily be integrated into larger system-level models created by other people in the development team.  The use of models and a modeling architecture strongly supports close team-based collaboration.

Use of simulation: simulation is the younger brother of testing.  Using models developers can quickly and easily exercise their models to determine the functional correctness of system under test.  Once the initial models are “correct”  they can be locked down with a set of formal tests.  Those formal tests often are derived directly from simulation used for design.

Model as the single truth: When we look at the elaboration process that a Model-Based Design process follows it is clear that the iterative nature of an agile process is a close fit.  Models can both provide a tight integration with requirements while allowing for the fast evolution of those requirements.  In fact, the use of simulation as part of the development process allows developers to quickly find issues with their requirements.

Final thoughts

Agile design processes are as good as the people who commit to them.  A good understanding of what is and what is not part of the agile development process is important to the success of the project.  (This is, of course, true of any product development.)  For another perspective on Agile development and Model-Based Design, this link provided a good overview.

This post is a companion post to the “Automation do’s and don’ts”.  Here I will examine organizational hurdles that stall the creation of reusable components.

The reuse of software is a common object stated by most companies, but, with exception of a set of narrow cases, most companies struggle with this objective.  In my experience, there are 6 reasons for this struggle

1. Lack of ownership:  There isn’t a group (or person for smaller companies) who has the responsibility and authority to ensure this task succeeds.
   Note: often the lack of authority on the person/groups part is the larger part of the problem.
2. Failure to allocate time:  Turning a component into a reusable component can add between 10% to 15% to the development time.  If time is not budgeted for the additional development a “buggy” reusable component is released.
3. Lack of awareness/documentation: The greatest software tool is useless if no one knows about it or it is poorly documented.
4. Narrow use case: The component is created and its’ use is so limited that only a few people will ever use it.
5. Wide use cases: Wide use cases often lead to complex reuse components that either do nothing well or become so bloated that they are difficult to configure and maintain.
6. Bugs: Every time a person uses a “reusable component” and it fails to do what it is supposed to do it encourages people to not look at reusable components.

So how do you avoid those pitfalls?

What type of reuse?

I break down reuse into two categories, formal and informal.  Informal reuse is common for individuals and within small groups.  It is when a component is regularly used to perform a task by people who know how to use it well or are able to work with its’ “quirks.”

Informal reuse is a good practice however it should not be confused with formal reuse which is the topic of this post.  With formal reuse, the component is used by people who are not experts on the underlying assumptions and methods of the object.  Because of this they are not tolerant of “quirks” and need a solution that is dependable and documented.

It should be noted that many “failed” reuse attempts arise out of taking informal reusable components and treating them like formal reusable components.

Deciding when to reuse

Before I automate a process I ask myself the following questions to prevent the “to narrow” and “to wide” blocking issues.

1. How often do I perform the task?
   Once a day? Once a week? Once a quarter?
2. How long does the task take?
   How long does the task take both for my self and the system running the process?
3. Do others perform this task?
   Do they follow the same process?  Does variance in the process cause problems?  Do you have a way to push the automation out to others?
4. How many decision points are there in the process?
   Decision points are a measure of the complexity of the process.
5. Is the process static?
   Is the process still evolving?  If so how often does it change?
6. Is it already automated?
   Oddly enough if you found it worthwhile to automate someone else may have already done the work.
   

Taking responsibility

Issues 1 (lack of ownership) 3 (lack of awareness and documentation, and 6 (bugs) can be addressed by having a person or group who has the task of creating and maintaining components

The maintenance of the component has three primary tasks.  First, the creation of test cases to ensure the component continues to work as expected.  Second, updating the component to support new use cases.  Third, knowing when to “branch” components to keep them from becoming to complicated.

Time

For some organizations allocating time to the development process can be the greatest hurdle to creating reusable components.  The time invested does not show an immediate return on investment and there are pressing deadlines.  However, if the rules of thumb in “deciding when to reuse” are followed the long-term benefits will outweigh the short-term cost.

Final thoughts

The final topic is how to encourage engineers to actually reuse the components.  This is, in part, dependent on how well the components are documented and how easy they are to accesses.  In the end, they need to understand how it benefits them; e..g less time spent “reinventing the wheel” and more time to work on their actual projects.

Anyone who has worked with software for more than 3 years knows that migration between software releases is a fact of life; having that process be smooth and easy is not always a fact of life (anyone remember Windows ME pains?)

Making migration easy(er)

One of my early swimming coaches was famous for saying “you win the race by how you train.”  I have found this advice to be true in most aspects of my life.  Projects succeed or fail based on the preparation you do as much as your execution.

Preparing for migration

In preparing for migration I start by asking 3 questions

1. What things are we doing now that are working well?
2. What things are we doing now that are hard to do?
3. What things do we want to do that we can’t do now?

The first question focuses on maintaining current functionality.  The second and third look at how to make things better.  Improvements to processes can be made either through refactoring of existing processes (or creating new processes) or through the adoption of new tools.
One of the critical things to keep in mind with software upgrades is that it is not just changing tools.  It is, or should be, about changing processes.  [Note: for minor migrations of a single tool the associated processes may or may not require updates.]

A few thoughts on type two problems

The “type 2” problems, “what things are we doing now that are hard to do?” can be further thought about in a few components.

• The process runs slowly:  Frequently, but not always, upgrades in software can provide an increase in speed.  Additional, process changes, may provide speed improvements.
• The process is complicated to execute:  Complex processes can be difficult to execute. Often complex processes were developed due to limitations in the tool when they were initially developed.
• The process has bugs: Before upgrading software validate that the bugs in the software have been resolved.

The more things change the more they stay the same…

When you upgrade you still want some things to be static: your results.  The best method for ensuring that your results (deliverables, code,…) remain the same is by developing test cases that “lock down” your deliverables.

When comparing test results between different tools there are a couple of things to keep in mind.  First, for every test as “acceptable” change should be defined as there may be small deviations which have no effect on the overall systems performance (though for some tests no change will be allowed.)  Second, in some cases testing in newer versions of software bugs that were not detected before may be uncovered.

Testing the testing environment

As a last note; if as part of your migration you are are updating your testing environment then you need to validate the behavior of your testing environment.  This is generally done through manual inspection of a subset of the full test suite.  The key factor is to have a subset that contains a full set of all types of tests are performed by the testing environment.