|
|
|
|
||
| February 2002 | Vol. 3 Issue 2 | |||
|
|
Inside This Issue
|
|||
|
****** NEW! ****** |
FAA DO-178B Training From Enea TekSci Mention DDC-I and Save 50%! For over 11 years, Enea TekSci has been one of the fastest growing real-time embedded consulting companies, and avionics has been a mainstay of that growth. Today, our avionics capability in requirements, systems engineering, architecture, design, code, test, certification, DO-178B processes/training, and DER approval makes us the largest such company in the world. Enea TekSci provides both on-site and off-site training in the FAA's civil avionics standard, RTCA DO-178B. The 2-day course is taught by several of Enea TekSci's Sr. Engineers and FAA-Designated Engineering Representatives (DER's). The course instructors are of the highest caliber available anywhere in the world, and have many years of hands-on experience designing and certifying software to DO-178B standards. All past attendees have called it one of the most valuable training experiences they've ever had. Our next public training class is in Phoenix, Arizona April 18-19. Mention DDC-I when registering and attend for ½ price! Spaces are limited, so please register soon!
On the Front Lines
As Support Manager for DDC-I A/S, Thomas Hansen is responsible for all customer care activities in Europe and Asia. This includes pre- and post-sales customer support, as well as management of help desk activities, product shipments, and quality control inspections. In 1987, Thomas joined the DACSTM (DDC-I Ada Compiler System) team working on the development of the 80x86 Run-Time System, and gained an intimate knowledge of the entire compiler system. Additionally, Thomas has valuable specialty experience with board support packages (UCCs), compiler validations and general trouble shooting. Thomas grew up in Copenhagen, Denmark, where he graduated with an MS in Electrical Engineering from the Danish Technical University in 1986. He currently lives in Copenhagen and enjoys photography, snow skiing, and experiencing the many advantages of GPS technologies.
Run and Debug Your Embedded 80x86/Pentium Code on a Plain PC in Real-Time By Thomas E. Hansen In the past, an embedded 80x86 or Pentium target normally implied some unique Single Board Computer (SBC) being software compatible with nothing but the CPU itself. These SBCs were very expensive and not at all fast - at least when compared to the contemporary PCs of that time. The peripheral chips would often vary between boards, and if there were any commonalities between the boards, you could almost rely on the wiring and interrupt routing being different. All this meant that new board support packages had to be configured when changing target boards. Today, an embedded 80x86 or Pentium target is very often PC compatible, which means that they can share board support packages. Thanks to the developments in micro-electronics, these boards have become very compact - down to credit card size or even smaller. DDC-I's PC/Bare solution helps you take full advantage of this evolution. Let's first establish what exactly PC/Bare really consists of: User Configurable Code (UCC) or Board Support Package Debug Monitor on Bootable Diskette Disk Load Tool Boot Diskette Creator Thus, PC/Bare enables you to link embedded applications to be executed on a standard PC. This can be most useful, for example in the early phase of a project, when the actual target hardware may not be available to all programmers. Using a standard office PC with PC/Bare you can code, debug and test algorithms using the exact same run-time system and compiler as you will eventually use for the embedded target because you have now turned the PC into an embedded target. Native compilers are often used for this purpose, but that may give a false sense of security because the code and run-time system will be different. Going back to the actual targets, there is a significant trend that bare target boards really are small PCs, possibly with less RAM and maybe without a video or keyboard controller. PC/Bare is ideal for this type of target. In most cases, the standard pre-configured UCC supplied by DDC-I will work with your embedded PC without change. Many of these targets even have some form of FLASH disk which is fully compatible with an ordinary disk, so all of the above tools can be used without change. Obviously, there may be special needs, which can be accommodated by minor adjustments to the UCC, but all essential drivers for UART, interrupt controller, timer, etc. remain unaltered. In other words, reduced risk and substantial savings are on the table. PC/Bare is available for both DACS-80x86 as well as SCORE-80x86. With either tool, you can run applications on your bare target from day one.
Tech Talk: Using
Ada Library Information By Jesper Jørgensen The following describes how the SCORE command-line tools for extracting Ada library information can be used for various tasks. UNIX is known for its wealth of simple commands that can be easily combined to perform even very complicated tasks. For example, many UNIX commands have the so-called "filter" property, meaning that they read from standard input and write to standard output. The SCORE command-line tools easily fit into this environment because the output is written to standard output that can be piped into any UNIX filter. Let's see some examples. 1. Using unit names instead of file names I find that I often forget the exact file names for my sources, especially the names of the directories in which they are placed. For me it is much easier to remember the unit names. Fortunately, I can exploit that the source file names are kept in the Ada library for any of the compiled units. To display the source file for the body of the unit myunit, the following SCORE command can be used:
This command can be combined with standard UNIX tools to give some very useful functionalities. For example, the source file can easily be displayed with this command:
Here the SCORE command show_unit is first invoked. It will print the source file name of the unit on standard output which is then used as parameter for the UNIX command more. Note that by using the -library option rather than the -path option, we can display units from any of the parent libraries too. When working with a particular project, the library is always the same so there is really no point in writing it every time we need to look at a file. Therefore, we can save typing by providing show_unit with mylib.alb by preparing a .scorerc resource file in the project directory containing this line:
Now the above command can be written:
We can save even more writing by defining a command for the above functionality. This can be put in a shell script file or a Bourne shell function can be written for it:
Note that function parameters are passed on to show_unit. This makes it possible to use all options known by show_unit for amore. Examples: Show the specification of myunit2 placed in the library myotherlib.alb:
The fact that we deposit the information on which library to use in a project/directory-specific resource file rather than in the function declaration, makes it possible to reuse the same command for every Ada project. It just requires a resource file for each project specifying the project library. Here are other examples of using the output of show_unit:
is a function that will allow you to diff your current source file version for any unit with the currently checked in version of the file (here shown with CVS as the version control system, but any system will do):
and
will start an editor (the preferred editor is usually specified by the EDITOR environment variable on UNIX). 2. Handling of all units of a partition (the Ada 95 term for a program) The SCORE command process_partition is used to display information on all the units that will be included in a link of a given partition. In its simplest form:
it will display the source file names of all the units that are linked into myprogram on standard output. Thus a sorted list of the file names can be found by this command:
Here we assume that you have specified the library search path in the .scorerc file as above. If more complex operations are needed that does not work solely on the source file names, the template option can be used. For example:
will produce a listing (one line per unit) of your partition in this format:
...
The color coding shows which template expansion specifiers get expanded to which output parts. The full source file name is obtained by the template expansion specifier &F. This example:
will copy all source files to the backup_src directory by constructing a copy command for each file and pipe the commands to /bin/sh for immediate execution. The above could also be achieved without a template by this command:
If you only want files for units in your own working library, do this:
The use of -path on this command line will override the library search path given in .scorerc.3. Using Windows NT command-line The above functionalities can also be obtained on Windows NT although a bit less elegantly due to the restrictions in the Windows NT command interpreter. The SCORE commands on Windows NT are exactly the same and with exactly the same functionality as on UNIX. A little tip: create bat-file scripts on Windows NT where you would make Bourne shell scripts on UNIX.
Customer Interaction and Software Development By Linda Rising Introduction John Muir was the founder of the Sierra Club. His classic statement: "When we try to pick out anything by itself, we find it hitched to everything else in the Universe." reflects his view on the interconnectedness of things. This paper will show that his observation applies to software development as well, in particular, the link between customer interaction and the software development process. What Are Patterns? Those of you who have been reading previous articles know that patterns provide a way of documenting well-known solutions to recurring problems. They are the epitome of reuse. By sharing what has worked in the past, experts can pass along knowledge to novices and all learn something! Patterns are appropriate for analysis, design, coding, testing, configuration management, training, and other phases of software development. They are also appropriate for organization and process. This paper describes patterns for customer interaction. Many of the Customer Interaction Patterns were mined from a
presentation to prepare a product development team for their first
interaction with the customer. The customer relationship is important
to developers throughout the development life cycle. Many team members
are involved one-on-one with a specific customer representative to
coordinate the flow of information from the customer to the
development team, and from resident subject matter experts to the
customer. After the beginning set of patterns had been documented,
they were reviewed and workshopped extensively, and other patterns
added along the way. They have been published [Rising00] and are
available on my web site. Here is a list of the patterns in the current version of the collection: It's A Relationship, Not A Sale In this article, only one of these patterns will be described, the foundation of the collection. It's A Relationship, Not A Sale, the overarching pattern for this collection. The other patterns support it and provide ways of implementing it. This pattern was adapted from a guidelines by Jim McCarthy [McCarthy95]. Pattern Name: It's A Relationship, Not A Sale Jim Coplien's Engage Customers (closely couple the customer role to the Developer) [Coplien95] and Bruce Whitenack's Customer Rapport (develop a rapport with the customer) [Whitenack95] define the context for this pattern. Forces:
Solution: Develop a relationship with the customer. Focus on this relationship, not the current transaction. It’s critical to Know the Customer (a Customer Interaction pattern) and then use that understanding in your product or service as part of an ongoing commitment to Build Trust (a Customer Interaction pattern). Resulting Context: Customers will feel they're buying into a relationship, not just buying a product. Your customers will feel like staying with you. Your customers will sense that you are going somewhere together. A long-term relationship means repeat business. It’s much cheaper to keep a customer than to find a new one. Having a good relationship with a customer is not enough to ensure financial success. Innovative solutions may capture markets regardless of customer relationships. The solutions in these patterns are only part of an overall business plan that includes attractive, innovative products. Rationale: On many projects, developers need a customer contact to answer questions that arise during development, and usually, team members simply want a name and a phone number. Having a person to call is not enough, a relationship with the customer will give the results developers want. The relationship with the customer is like a dance. You take steps, and the customer takes steps in response, and then you take more steps. You must be focused on the flow of transactions, on the overall pattern and direction, not merely on the current product. Human relationships are fragile and not formed instantly but develop slowly and evolve over time. The following is from Selling with Honor [Kohn97]:
The following is from Dan Behymer, director of quality systems at a manufacturing facility in Cincinnati [Behymer97]:
Impact on Development Process Most software development follows the waterfall model, where a fairly long period is spent developing a requirements specification. When the requirements phase is finished, most project managers feel that requirements definition is complete. Milestone meetings might be held with the customer throughout development to report on progress and deliver documents but it is not the intent of these meetings to revisit or redefine requirements. In some cases, no other contact with the customer is scheduled. Since final release is scheduled for many months later, a long time could elapse between the initial requirements phase and the delivery of a completed system. Having only a single requirements phase means that customers will say, "Here's everything I could possibly want—because this is my only chance to get everything on your list!" Consider for a moment, the complete turnaround that is happening in today's chaotic development environment. Requirements are never completely defined up front. It's impossible. Customers often do not know precisely what they want. They just know they want it in six months! The only hope for delivery of a successful product is to work closely with the customer and examine the changing marketplace to decide together what the product will be. This approach gives customers less chance to get nervous—customers tend to get nervous over time. As customers and developers learn together, the requirements evolve based on a clearer understanding of the possible, not the pie-in-the-sky approach that can result from an attempt to define everything up front. When you have something to show the customer, they're more willing to work with you and better able to say what they want and will accept. This allows customer input to be well integrated with product development. Feedback that arrives after the product is completely finished is more difficult to apply. This enables the team to work smart, cut unnecessary work and put their best effort into the things that really matter to the customer. This kind of development requires different customer interaction skills. The relationship is more collaborative. The pattern, It's a Relationship, Not a Sale! says exactly that. The focus is not on a specific product but on developing a relationship with the customer. Only in this way, can we be successful in producing what the customer wants. Applying this pattern leads a team to have the right perspective for the changing development process. As you have read in my article on agile processes, having an on-site customer or customer representative is key. The team works closely with the on-site customer to be sure that questions are correctly answered. Instead of relying on intuition or what might be fun to develop, the team’s response follows the business needs, the needs of the customer. Postmortem Learnings A retrospective or postmortem at the end of a project helps an organization learn what worked well and what should be done differently on succeeding projects. The comments below are from successful team postmortems and illustrate the use of the pattern, It's a Relationship, Not a Sale.
Summary There seems to be a clear connection between the software development process and customer interaction. Just as patterns in a given domain are linked to help a user solve problems in that domain, so patterns in software development are tied to organization of the team and the process the team follows and that includes customer interaction. References [Behymer97] Behymer, D., Letter to the editor, Quality Digest, May 1997, 10. [Coplien 95] Coplien, J.O., "A Generative Development-Process Pattern Language," Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, 1995, 184-237. [Kohn+97] Kohn, L. and J. Saltzman, Selling with Honor, Berkley Books, 1997. [McCarthy95] McCarthy, J., #17, "It's a relationship, not a sale," Dynamics of Software Development, Microsoft Press, Redmond, WA, 1995, 71-73. [Rising00] Rising, L., "Customer Interaction Patterns," Pattern Languages of Program Design 4, Harrison, N.B., B. Foote, H. Rohnert, eds., Addison-Wesley, 2000, 585-609. [Whitenack95] Whitenack, B., "RAPPel: A Requirements-Analysis-Process Pattern Language for Object-Oriented Development," in Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, 1995, 260-291. About the Author Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in Fall 2002. Customer Interaction continued... Sidebar Story from The Invisible Computer, Donald A. Norman, The MIT Press, 1999. Thomas Alva Edison was a great technologist—one of the best—but not a great businessman. Edison invented the phonograph in 1877, and by 1878 was marketing the first machines. People weren’t quite sure what to do with the new machine, and at first, it was used primarily for public demonstrations (with paid admission). Edison thought it could lead to a paperless office in which dictated letters could be recorded and the cylinders mailed to the recipients. He also tried putting a small phonograph into a doll and selling it as a talking toy. Owners of the early machines held parties where guests could record songs and then enjoy listening to them being played back. The practical phonograph did not arrive until the late 1880s, by which time there were serious competitors, including the American Gramophone Company that recorded on wax-coated cardboard cylinders and, in the early 1890s Emile Berliner became the first to produce prerecorded stamped disc records commercially with his machine, the gramophone. Edison’s phonograph had a number of superior features to the competition. But having the best technology is no route to success. Sony’s Beta technology for videocassette recording is widely considered to have been superior to the VHS format for videocassette recorders and tape, but Beta lost. The Macintosh operating system clearly had advantages over DOS, but it lost, first to DOS, and then to Microsoft Windows, a system that took ten years to catch up to the Macintosh, but that now dominates the world of computers. When Edison invented the phonograph he studied the cylinder and the disc and recognized the superiority of the cylinder as a recording medium. The cylinder’s semi-permanent jeweled stylus was more convenient than the disc’s steel needles, which had to be changed after every record side. But the discs offered many advantages over the cylinders. They were less fragile. Their hard shellac surface allowed greater playback volume, if a more raucous, scratchy sound, than the soft wax cylinders. They took up far less space, and were easier to store, package, and ship. They could accommodate longer playing time simply by increasing their diameter, and they had a second side that could provide more music without increasing storage space, for less money. Most important, they were far easier to mass-produce. Eventually Edison did realize the importance of compatibility and convenience but by the time he switched over to discs in 1913 he was no longer the market leader. Even after he began manufacturing discs, Edison continued to use the vertical recording method. The competition used lateral recording. Early phonographs could only play back one system, either vertical or lateral, so whichever system customers bought, they couldn’t play back the recordings of the other. When the infrastructure of one company differs from that of another and you have the dominant infrastructure, you win. If you choose the wrong one, you lose, and you lose big. The Victor Talking Machine Company had the dominant infrastructure, and Edison lost. The real use of the phonograph record, discovered after much trial and error, was to provide prerecorded music. Emile Berliner moved quickly to exploit this and his company rapidly picked up a dominant market share. His gramophone became the Victrola, manufactured by the Victor Talking Machine Company, later RCA Victor. Berliner and his successors rapidly established recording studios across the world and engaged the world’s most famous musicians. Edison decided that big-name, expensive artists were not much different from the lesser-known professionals. In this, he is probably technically correct. Edison thought he could save considerable money at no sacrifice to quality by recording those lesser-known artists. He was right; he saved a lot of money. The problem was, the public wanted to hear the big names, not the unknown ones. As a Victor advertisement put it:
Edison pitted his taste and his technology-centered logical analysis on the belief that the differences among musicians were not important: He lost. He thought his customers only cared about the music; he didn’t even list the performer’s names on his disc records for several years. He failed to understand that people wanted to hear the big names. It doesn’t matter if others are just as good. It doesn’t even matter if they are better—it’s the name that matters. This would have been less important had it not been for Edison’s choice of vertical recording that was incompatible with the lateral recording machines most people owned. If Edison had used the same standard way of recording as his competitor, then it wouldn’t have mattered that the big names were on Victor records. People would have been able to buy Edison phonographs and play Victor records. But with a specialized, incompatible infrastructure, if customers wanted the name musicians, they had to buy both the records and the phonographs from Victor. Eventually some companies did make instruments that could play both kinds of records, but by then, it was too late. The Victor Talking Machine Company cemented its lead over Edison when it introduced the Victrola in 1907; this machine, with its amplifying horn concealed within the cabinet, became so popular that the word "Victrola" became the generic term for any record player for the next 50 years. Again, understanding the desires of the customer, who was growing tired of the intrusive, ever-larger horn, let the company maintain its dominance in the market. Note the moral of this story, for it will apply over and over again in the high-technology marketplace. Know your customer. Being first, being best, and even being right do not matter; what matters is what the customers think. |
Introduction to Ada95: --------------- FAA DO-178B Basic Seminar FAA DO-178B Applied Seminar --------------- Seating is Limited!
|
DDC-I Online News is published by DDC-I, 400 N.
5th Street, Phoenix, AZ 85004. Editor Jennifer Sanchez.
Comments and submission of articles are welcome and should be sent to the
editor at the address above or via email at editor@ddci.com.