The Path to Being #1 in Customer Care By Monica Holt When the agreement has been signed, the deal has been sealed and the product delivered, the real work begins. As with any new purchase, whether it's a new phone from the local communications inc. or a new SCORE compiler from DDC-I, there are different stages of user activity that exist. In the beginning, the user needs to get to know the product, what it does and how it does it. After a comfortable level of comprehension settles in, one can start to use the product for its designed purpose. In good time, the user can make the product perform with ease. However, not every program sings along in harmony. Running into difficulties and questions directly impacts the effectiveness and efficiency of any stage of development. Most customers realize the importance of each stage of progress. DDC-I sees the genuine need to provide a dynamic support network to minimize problems and get results for its customers. There are members of this organization from every department including engineering, marketing and sales who solely work to provide high quality service to the customer. Due to the nature of the products that DDC-I offers and the eclectic mix of individuals that use these products, DDC-I has worked tirelessly to match the support program with this human environment both at the Phoenix and Denmark office. A few years ago, the entire technical support program was revolutionized in an effort to better serve the customer. What manifested from this renovation was the Atlas Support Program with three packages specifically designed around the idea of the three stages of development. Atlas Premium caters to that initial development stage offering immediate access to telephone and email support along with DDC-I's very own Jump Start workshop. The workshop is an on-site visit to help the customer through the installation process step by step. After the first stage is over, a customer has the option to move to Atlas Advantage, which offers expert support and services designed for the experienced user. Lastly, the Atlas Choice program is offered during the final stages of the development. Atlas Choice lets the user choose from a list of options ranging from software subscription to telephone and email support. The entire DDC-I staff is a pool of unique and talented individuals, each with an understanding that establishing relationships and forming partnerships with the users will be the determining factors to better serving the customer. A sense of security and accountability has been established and continues to keep DDC-I support packages in demand. With an overwhelming percentage of support contract renewals this year, the numbers reflect the feelings of DDC-I customers. DDC-I is definitely on the right path! Agile Methods: What’s it All About? By Linda Rising Adaptive Software Development, Crystal, eXtreme Programming, Scrum, and others are "hot" software topics right now. What are these methods all about? Where are we going with software processes? Agility is the defining buzzword these days—not only for software development methodologies but also for organizational concerns at any level. The agile organization will be able to survive in the turbulent times ahead, while the rigid, hierarchical structures will not. Simple. Let me assure you that the information in this report reflects the latest information on these agile approaches, which seem to be changing as rapidly as the teams that use them. I attended a workshop on agile approaches at the recent OOPSLA Conference (October 14-18, 2001). Other attendees at this workshop included developers of many of these approaches (and the authors of the books with more information). This article is not a comprehensive overview but will include pointers if you want to head off on your own to learn more. Let’s start by looking at a list of commonalities. Most of these methodologies share a focus on:
The reasons for these commonalities support the image of agile and lightweight development. No heavy-duty process, no reams of useless documentation to weigh down the process. Kent Beck uses the phrase "intellectual nomads" and the image is clear. The team is ready and able to change direction when the customer or the world demand it. Some of these methodologies are better known than others. The best known are:
eXtreme Programming (XP) XP is probably the best known today and that’s probably because of the number of books that have been published—six, I think, although, at the rate they’re appearing I could be wrong. Kent Beck is the originator of the approach, so I like his book best—and it was the first. XP has a set of values and principles that define the approach. The values are:
Communicate with your customer and your colleagues. Use simplicity throughout. Test the software and the process continuously to learn what’s working and what isn’t. Many of the heavyweight processes are based on fear. XP uses courage instead. The practices:
More information on XP: http://www.xprogramming.com/ Crystal
The process in a nutshell: set up the first increment, learn, set up the next increment, and so on. Give the process to the team and allow them to change it. Alistair will not tell you exactly what to do except:
Jim Highsmith, author of Adaptive Software Development, and Alistair have decided to unify their work on light and self-adaptive methodologies. For more information see: http://crystalmethodologies.org/index.htm Adaptive Software Development
For more information: http://www.adaptivesd.com/index.html Scrum The process begins by creating the project backlog—a list of all deliverables. These can be user stories (as in XP) or requirements. The backlog is never empty as long as the program is maintained. It constantly changes. It is updated by only one person, the designated project owner, who also sets the priority of the items. The backlog is always visible and anyone can influence the project owner. The project is divided into 2-4 week Sprints (the length varies among projects). Each team keeps a team backlog, which constantly changes. All stake holders meet to determine what will be done in the next Sprint. A deliverable must be complete—a visible, usable increment (that builds on previous increments as development proceeds). The backlog creation and setting of priorities should be done with the customer (one of the stakeholders). During a Sprint, no interruptions are allowed from the outside. A short meeting is held daily or every other day where the team lead or ScrumMaster asks three questions of every team member:
At the end of the Sprint the stakeholders meeting is held.
Experience from earlier increments allows better estimates and planning as project progresses. It's always easier to estimate shorter development periods. For more information—including a new book just out: http://www.controlchaos.com/ Inappropriate projects In a follow-on article, I will talk about the process improvement that I believe had the biggest impact on projects in my experience. Stay tuned! Tech Talk By Johan P. Olmütz Nielsen The following describes how to use SCORE to build a program which consists of both Ada and C sources and which has a C main program. The examples show native commands for brevity but the commands work the same for cross targets. Imagine that you have the following C application static int process(int init) /* Temporary stub */
{
return init;
}
int main(int argc, char **argv)
{
int seed = 12;
return process(seed);
}
and want to use some Ada code which already implements the processing algorithm. Your existing Ada code looks like this (at least after the addition of the pragma Export, which we need to give the name we will use when calling from C): package Useful_Operations is
function Process( Seed : in Integer ) return Integer;
pragma Export( Convention => Ada, Entity => Process, External_Name => "process" );
end Useful_Operations;
package body Useful_Operations is
function Process( Seed : in Integer ) return Integer is
begin
return Seed * 10 + 3;
end Process;
end Useful_Operations;
Notice that the Ada function could have been written using the type Interfaces.C.int and with the convention C to prepare the function for use from C. This is not required as the predefined scalar types in C and Ada (e.g. int and Integer) map to one another in SCORE. It is beyond this note to describe exactly how to write the correct Export pragma except that the calling convention can be Ada or C when the parameters and result all are integers, floats or pointers. Compile all the Ada sources to be called from C. We create a partition Ada_Ops which contain all the Ada units we need in our mixed application - note that all indirectly needed units are automatically included. Note also that the linking is postponed until we have the C part in place. $ ada -parse useful_operations*.ada
$ create_partition Ada_Ops Useful_Operations
$ make_partition -nolink Ada_Ops
We now turn to the C source. We replace function process with an external declaration and insert calls to the functions adainit and adafinal (described in [ARM B.1.39]). Make sure all calls to Ada occur between these two calls. The result looks like this: extern int process(int);
extern void adainit(void);
extern void adafinal(void);
int main(int argc, char **argv)
{
int seed = 12;
int result;
adainit();
result = process(seed); adafinal();
return result;
}
Now compile this file: $ tcc -c main.c and we are ready to link the mixed application. First we will let the Ada linker link the complete program (although the main program comes from C): $ link_partition -noadamain -object main.o -output mixed_app Ada_Ops If we run the application we can check that it works as the result (the exit code) must be 123. Finally we will look at how to use tcc to do the link. First we build the Ada part: $ make_partition -noadamain -stop_before_link Ada_Ops This results in the file Ada_Ops.bat. In it you can see the names of the extracted Ada object files, the elaboration module and the selected Ada run-time system. You need to include these items in your tcc link. It may look like this (note that -g must be specified because some of the predefined Ada units are compiled with debug): $ tcc -o mixed_app -g main.o /tmp/al_1.o /tmp/al_2.o /tmp/al_3.o
/tmp/alm_0.o <SCOREHOME>/native/lib/librts_nt_np_na_nh_e.a
An alternative could be to make a custom link template which would collect all the Ada object files in an archive so that they would be easier to include. Again, we may check that the application gives the result 123. |