Darren O'rourke

Pilot eLog – A Study in Technical Management and Software Engineering

by Darren O’Rourke

A MASTER OF ENGINEERING REPORT

Submitted to the College of Engineering at Texas Tech University in Partial Fulfillment of The Requirements for the Degree of

MASTER OF ENGINEERING

Approved

______Dr. A. Ertas

______Dr. E.W. Kiesling

______Dr. T.T. Maxwell

______Dr. M.M. Tanik

October 15, 2005

ACKNOWLEDGEMENTS

I would like to take this opportunity to acknowledge those who have supported me throughout this unique educational experience. Throughout our lives we enlist the help of our respective support systems to meet our goals. For me, this endeavor was no exception. The people in the following paragraphs are a part of that support system and their contributions in helping me played a significant role in the completion of the Texas Tech University/Raytheon Master of Engineering degree program.

First, John O’Rourke, my father, an educator, who instilled in me the noble idea of bettering one’s self through the pursuit of higher education and the curiosity to seek answers to life’s questions. I would like to thank him also, for giving me the drive to see things through to the end and for shaping me into the man and the husband I am today.

Second, I would like to thank the members of my extended family who played a role in who and where I am in life. In addition, I would like to acknowledge my wife’s extended family, for teaching me that even if you sometimes disagree with one another; you still come together and support each other.

I would like to extend a very special thank you to my mother-in-law, who puts up with a lot of grief from me, especially this past year. She handles many household responsibilities, allowing my wife and I to take advantage of opportunities outside the home.

I would like to express thanks to Dr. Ertas, Dr. Maxwell, and all of the instructors for the opportunity to participate in the program and for their classroom

iii

instruction. Thank you to Steven Huss, Stan Kopec, for organizing and scheduling the classrooms and handling of the needs of the students. Thanks are due also to

Pam Tarver in the Engineering Department and Deb Crosby in the VA Affairs office on the Texas Tech University campus for the time and effort they spent handling additional administrative tasks for me with regard to my Veterans benefits.

I would like to thank my friends. Particularly, Scott and Brenda Burnell, Mark

Manners, Brad Webb, and my former supervisor, MSgt Chuck Watson (USAF

Retired), for their assistance and encouragement. Thanks are due especially to

Michael Hogan for convincing me to participate in the program and for sharing the hours upon hours of toil with me throughout the past year on the program. And, a special thank you goes to my classmates, most of whom somehow managed to practice adequate restroom hygiene throughout the past year.

Finally, and most importantly, thank you to my wife, Martha. Her dedication and sacrifices enabled me to complete the program. She is a woman of uncommon character who picked up the slack with many household tasks and allowed me to put important home projects off while I was in class, studying or working on projects for the master’s program. Even though she is a college student and has a fulltime job herself, she sacrificed, encouraged, and motivated me to push myself when it seemed I was too tired to continue. Her confidence in me helped drive me to finish the most difficult classes. I could not have done this without her and this report is for her.

TABLE OF CONTENTS

CHAPTER I INTRODUCTION ...... 1 CHAPTER II POSSIBILITY – CREATING A CORPORATE VISION ...... 3 2.1 VALUES...... 3 2.1.1 Integrity ...... 6 2.1.2 Trust ...... 6 2.1.3 Diversity ...... 7 2.1.4 Openness ...... 8 2.1.5 Excellence...... 8 2.1.6 Initiative...... 9 2.1.7 Teamwork...... 9 2.1.8 Taking Care of Each Other...... 10 2.1.9 Community Involvement & Social Conscientiousness ...... 11 2.1.10 Fun ...... 12 2.2 VISION ...... 12 2.2.1 Who Do We Hire...... 14 2.3 PURPOSE...... 15 2.4 ENGINEERING METHODOLOGIES ...... 16 2.4.1 Software Engineering Methodology ...... 16 2.4.2 Software Maintenance Methodology ...... 21 2.5 ENGINEERING STANDARDS AND GUIDELINES...... 24 2.5.1 Documentation Standards ...... 24 2.5.2 Software Coding Standards ...... 25 2.5.3 GUI Implementation Framework ...... 27 CHAPTER III TIMING ...... 29 3.1 GROWTH STRATEGY...... 29 3.1.1 Staying Current with Technology ...... 29 3.1.2 Increasing Customer Base...... 29 3.2 CORPORATE ROADMAP ...... 32 CHAPTER IV LEVERAGING...... 33 4.1 CREATING ADVANTAGE ...... 33 4.2 TECHNOLOGY ...... 33 4.2.1 Software & Software Development Tools ...... 33 4.2.2 Business Support Software...... 34 4.2.3 Hardware...... 34 4.3 CORPORATE INFRASTRUCTURE ...... 34 4.4 TAKING ADVANTAGE OF EXTERNAL RESOURCES ...... 34 4.4.1 Online accounting and Payroll services ...... 35 4.4.2 Advertising ...... 35 4.4.3 Online Payment Solutions...... 35 CHAPTER V MASTERY ...... 36 5.1 BUILDING CORPORATE KNOWLEDGE...... 36 5.2 TRAINING ...... 36 5.2.1 Technical Training ...... 36 5.2.2 Non-Technical Training ...... 37

CHAPTER VI LEADERSHIP ...... 38 6.1 DEFINITION...... 38 6.2 THE DIFFERENCE BETWEEN LEADING AND MANAGING ...... 38 6.3 DEVELOPING LEADERS ...... 39 CHAPTER VII THE PRODUCT ...... 42 7.1 STATEMENT OF WORK...... 42 7.1.1 Project Overview ...... 42 7.1.2 Preliminary Requirements ...... 42 7.1.3 Project Schedule ...... 44 7.1.4 Development Environment ...... 44 7.1.5 Version History...... 44 7.2 REQUIREMENTS SPECIFICATION ...... 45 7.2.1 System Overview ...... 45 7.2.2 Reference Documents ...... 45 7.2.3 Requirements...... 45 7.2.4 Notes ...... 49 7.2.5 Version History...... 49 7.3 DESIGN DOCUMENT ...... 50 7.3.1 Scope ...... 50 7.3.2 Design Constraints ...... 50 7.3.3 Design Approach ...... 50 7.3.4 Top Level Component Identification ...... 50 7.3.5 External Interfaces ...... 52 7.3.6 Detailed Design ...... 52 7.3.7 Risks and Issues...... 64 7.3.8 Version History...... 64 7.4 TEST PLAN AND TEST CASES ...... 64 7.4.1 System Overview ...... 64 7.4.2 Test Plan ...... 65 7.4.3 Test Cases ...... 65 7.4.4 Version History...... 70 7.5 IMPLEMENTATION PLAN ...... 71 7.5.1 System Overview ...... 71 7.5.2 Implementation Steps...... 71 7.5.3 Implementation Backout Steps ...... 71 7.5.4 Version History...... 71 CHAPTER VIII CONCLUSION ...... 72 APPENDIX A: SOFTWARE DOCUMENTATION TEMPLATES...... A-1 APPENDIX B: SOFTWARE CODING STANDARDS ...... B-1 APPENDIX C: GLOSSARY ...... C-1

L I S T O F F I G U R E S

Figure 1: Software Development Process ...... 17

Figure 2: Software Maintenance Process ...... 23

Figure 3: Earnings Projections ...... 30

Figure 4: Potential Earning for 100% of Market ...... 31

Figure 5: Corporate Roadmap ...... 32

Figure 6: Evolution of Mastery ...... 37

Figure 7: System Project Schedule...... 44

Figure 8: Data Requirement Table...... 48

Figure 9: Data Flow Diagram...... 51

Figure 10: Functional Requirement Traceability ...... 52

Figure 11: Use Case Diagram ...... 55

Figure 12: Class Diagram ...... 56

Figure 13: Data Model Diagram...... 57

Figure 14: Data Dictionary - Part 1 ...... 58

Figure 15: Data Dictionary - Part 2 ...... 59

Figure 16: Data Requirement Map – Part 1 ...... 60

Figure 17: Data Requirement Map – Part 2 ...... 61

Figure 18: View Logbook Screen Layout ...... 62

Figure 19: Aircraft Screen Layout ...... 62

Figure 20: Add/Edit Entry, Main Tab Screen Layout ...... 63

Figure 21: Add/Edit Entry, Type of Hours Tab Screen Layout ...... 63

Figure 22 : User Profile Screen Layout...... 64

vii

DISCLAIMER The opinions expressed in this report are strictly those of the author and are not necessarily those of Raytheon, Texas Tech University, or any U.S. Government agency. Some of the information presented within this report is based on references and sources that are in development and have not been officially released to the public domain, or are in limited circulation by their respective governing authorities seeking comments. As such, utilization of information contained herein should be preceded with thorough investigation into the current state and appropriateness of references and sources listed at the end of this report in the REFERENCES section.

viii

ABSTRACT

The purpose of this report is to put into practice the skills learned in the course work for the Master of Transdisciplinary Engineering program. The goal of this report is to create the foundation for a company that will offer a web-based software service that is useful to a segment of the population. Using the knowledge gained from several of the Texas Tech University Master of Engineering courses taken in this program, a foundation for a software engineering based business and the methodology and process for building products in the context of that business can be developed. It is hoped that in laying the foundation for and implementing the philosophies and methodologies developed in this project, that the information expressed can be of help to other engineers.

The foundation for a business will be based on concepts developed by Dr.

Raymond T. Yeh, from his book, The Art of Business: In The Footsteps of Giants and in the Texas Tech University Technical Management course taught by Dr. Yeh.

Successful development of any business venture must start with an underlying philosophy that is clearly defined and permeates the culture of the business. In the course of this project I will define a vision that will encompass the following principles:

• Vision – A statement of whom we are and what we hope to achieve.

• Company Values – A set of values that will guide the company.

• Purpose – Defined goals for which to apply the company’s values.

The principles outlined above will be used as a guide for the rest of the concepts to develop the business. In the course of this project, I will also discuss the concept of Timing - how best to take advantage of current market conditions,

develop a roadmap to define the direction of the company, and a plan to influence the marketplace to the advantage of the company.

This project will also delve into the concept of leveraging. That is, taking advantage of existing resources to better the business and the business’ position.

This is especially important in this particular project because of the heavy reliance on the development of software - using resources that help the company to develop enterprise level applications in keeping with the corporate goals, while reducing overhead costs to maximize profits. Businesses utilize concepts of leveraging frequently and this project will be no exception.

We will explore the concept of Mastery. This will involve increasing business acumen as well as learning skills that improve the products and services that are offered to customers. More importantly, the idea of identifying and building leaders

(as opposed to managers) will be discussed in the context of the project.

Finally, the concept of Leadership will be explored. How one should approach leadership in the context of the project and of business. We will discuss the failure of many businesses in the area of leadership and ideas on how that might be avoided. Leadership is probably the most important concept when it comes to creating an environment that promotes the core philosophies of the business.

In the course of discussing these things we will be designing an application that will provide a web based service for a specific market. We will use strategies and concepts taught in the Texas Tech University Systems Engineering course,

Software Engineering course, Transdisciplinary Design course, and others as necessary to complete the project.

CH A P T E R I I NT RODU C T I ON

The Pilot eLog will be a web-based subscription service that will be a benefit, in the beginning, for civil aviators. Initially, the focus will be on aviators who have student and private certificates. The goal of the business is to create processes and standards of practice that will allow for the flexibility to expand our target market beyond the initial markets to flight instructors and possibly commercial pilots. In addition, flexibility may enable additional types of logs, such as automating the required logs for the long-haul trucking industry.

The idea for this project comes from two places. It comes from the passion of civil aviators across the country, which I learned of from my older brother, a private pilot, and someone who displays his passion in many ways. The second stems from the Technical Management course taught in the Master of Engineering program by Texas Tech University.

It is difficult to find any pilot who does not have a passion for flying. Most aviators belong to some form of flying club. There are a number of reasons for this. First, these clubs offer their members an opportunity to socialize and share their passion with one another. Second, flying is an expensive endeavor – it is getting more expensive every day with fuel costs skyrocketing – and forming a club gives members access to aircraft owned by the club at rates usually much lower than an FBO or flight school. The members pay for the fuel, maintenance, and insurance for the club’s planes through their monthly dues and rental fees. Third, members can use the flying club to improve their skills, initially learn to fly, or obtain additional ratings.

The second reason for the idea for this project comes from the Technical

Management course taught by Dr. Raymond Yeh based on his book, The Art of

Business: In The Footsteps of Giants and Dr. H. T. Yeh who has put the principles into action within the field of software engineering. Most software projects fail because they are poorly managed. Successful software project management is important to me. I decided to undertake this project to see if I could successfully put together the foundation for a company that can build software successfully by defining a set of methodologies that put Dr. Yeh’s philosophies about business into practice. Also, it is difficult to find any corporations that can successfully field software from top to bottom. While there are individuals and teams that are very skilled and repeat success, there are very few instances where it is done throughout a company. In the course of this report I will discuss where corporations fail in this regard.

As a result of pilots’ passion and the expense and time involved in flying and learning to fly, civil aviators generally do not have the time, the inclination, or the dollars to engage in activities that would take away from flying. There are not many flying clubs or schools that have web sites, and those clubs that do tend to keep them very simple so that they do not have to expend valuable time maintaining them. Additionally, not many FBOs and flying schools have much of a web presence. They have better things to spend time and money on than building or hiring someone to construct a web site.

These factors indicate that there may be an open market available to develop and sell web based tools to assist civil aviators in the activities that are required by the FAA and other entities with regard to flying.

CH A P T E R II P OS S I BIL IT Y – C RE A TI N G A C OR P ORA T E VI SI ON

2.1 Va lu e s

For any company, having a well-defined set of values is extremely important.

These values serve as a guideline for company. These values should become part of the corporate culture. They serve as a foundation for ethical behavior and set the company up for success. Since every position at the company is important to the success of the company, every member should share these values. The values that Pilot eLog, Inc will adhere to include:

• Integrity • Trust • Diversity • Openness • Excellence • Initiative • Teamwork • Taking care of each other • Community Involvement & Social Conscientiousness • Fun An important aspect that will help put values into their proper perspective is to define what success is to a corporation. Success has nothing to do with quarterly reports or the price of the stock. It has to do with how we serve our customers, how we serve our employees, and the impact we have on the local community and on society at large.

In general, too many businesses worry about the price of the stock and whether or not the company makes its projected quarterly earnings. When asked

how he managed the stock of his company, Art Collins, Chairman and CEO of

Medtronic, a medical technology company, said the following:

“I don’t manage the stock. We manage taking care of patients. That’s our business. Stock isn’t our business. There’s nothing we do that’s different because the stock is temporarily dropping. We’re in this for the long haul.”[1] Managing a business based solely on the price of stock or on making money gives the company no meaning. It cannot and will not have an enduring legacy.

More importantly, companies that value the price of the stock make other things expendable. Companies that value money over all other things will do anything to increase their bottom line. They will slash benefits, offer lower wages or lay off employees, or cut their level of customer service.

Success is shared between the employees and the leadership team of the company. Therefore, the company cannot be successful unless the employees are satisfied. At Costco, a national warehouse club, part of their mission statement is to “Take care of their employees”; it reads in part:

Our employees are our most important assets. We believe we have the very best employees in the warehouse club industry, and we are committed to providing them with rewarding challenges and ample opportunities for personal and career growth.[2] The above words are put into practice in a very real way at Costco, sometimes to the dismay of Wall Street analysts. Costco’s average pay is $17 an hour, 42% higher than their biggest rival, Sam’s Club, a subsidiary of Wal-Mart,

Inc.[3] Their health benefits require employees to pay only 8% of the cost of health benefits, while other companies generally require employees to contribute

25% of their paycheck to their medical plan.[4] Despite criticisms from financial

analysts, over the last few years Costco has made a bigger profit than Sam’s Club and its stock sells at a higher price than Sam’s Club parent company, Wal-Mart.[5]

Finally, success must include a positive impact on the local community and society as a whole. Corporations are not natural entities. They exist only because we have passed laws that allow them to exist. They have been granted the same rights of “citizenship” that are guaranteed by the 14th amendment to the United

States Constitution by our government. Unfortunately, many corporations do not feel obligated to fulfill the responsibilities that go with that citizenship. Success, in terms of a positive impact on the local community and on society as a whole starts with being a good corporate citizen. For an example, Ben & Jerry’s mission statement concerning social issues is:

To operate the company in a way that actively recognizes the central role that business plays in society by initiating innovative ways to improve the quality of life locally, nationally & internationally.[6] As part of this mission, Ben & Jerry’s puts out an annual assessment of their accomplishments and how they are doing with their mission statements regarding their social mission (stated above), their economic mission, and their product mission. This includes assessments with regard to philanthropy and community involvement, their relationship with their employees, and relationship(s) with their suppliers. In these reports, they pull no punches and are not afraid to state where they are failing and need to improve along with where they feel they have been successful.

2.1.1 Integrity

Integrity is defined as “1. Steadfast adherence to a strict moral or ethical code. 2. The state of being unimpaired; soundness. 3. The quality or condition of being whole or undivided; completeness.” It comes from the Latin integritas, meaning “soundness”.[7] It comes from the same root as “integer”, which in mathematical terms refers to whole numbers. In the context of a business, and in life for that matter, integrity takes on a deeper meaning. It means different things for different people within the company, but can be boiled down to a few core traits. It means conducting yourself in an upstanding manner. It means trusting those around you to do their jobs. It means treating people with respect and valuing their contribution to the company. It also means giving your best effort, admitting your mistakes, and making the proper changes to correct them.

2.1.2 T ru st

In order for a business to be successful, the employees must trust one another and must work to earn the trust of one another. Trust must exist from the lowest to the highest levels of management, as well as unilaterally. From the individual contributor level, employees have to trust their managers to deploy them as a resource in a useful way to help the company and must trust their corporate leaders to drive the company in a direction that benefits all the employees. At the supervisory and corporate leadership levels, they must trust their subordinates to deliver what is necessary to take the company in the direction it needs to go.

Finally, employees must be able to trust each other at the peer level. At Nortel, they refer to customers on two levels. Each employee has internal customers and external customers. External customers are the customers of Nortel itself. Internal

customers are customers who work for other business units within Nortel. Since business units are often highly specialized, Nortel employees are required to collaborate between business units. By using the language “internal customer”,

Nortel employees are expected to provide each other the same level of customer service that they give to an external customer to the company, which builds internal trust and reliability.[8] Management should assume that any person they hire is reliable and back them up even when honest mistakes are made. Mistakes are inevitable, but growth comes from learning and growing from those mistakes.

2.1.3 Dive rs it y

Diversity is the blending and working together of people from a wide range of backgrounds, including, but not limited to, personal ideology, education, religion, race, language and sexual orientation. An important aspect of these core values is the encouragement and respect for diversity. Diversity is not only important in order to create a positive work environment that is free from intimidation and promotes inclusiveness for all employees, but also because it makes a company stronger. The makeup of today’s marketplace for customers and potential employees requires us to have an understanding of all cultures to build relationships that transcend those cultures and across borders. In addition to creating an environment of inclusiveness and acceptance, having and respecting a diverse workforce will enhance the ability for employees to draw on the creativity, knowledge and support of one another to solve problems and meet the demands of their jobs, delivering the best products and services to the customers.[9]

2.1.4 Ope n n e s s

Openness to all ideas on how to better perform and adapt to the marketplace and its customers is at the core of Pilot eLog’s philosophy.[10] Employees will be empowered to bring new ideas to the table regarding everything from how the company does business, to how it deals with its customers, to new ways to interact with the community and/or make a more positive impact on society. Ideas can come from anywhere, including outside the company. Employees are encouraged to bring whatever ideas they believe will make the company better, from how it conducts business to what social issues the company aligns itself with. By encouraging the workforce to innovate and bring new ways of doing business, we also build trust and give each employee a stake in the success of the company.

2.1.5 E x ce lle n ce

The nature of competition requires hard work to be successful. We live in a society that has an amazing work ethic. To that end, the company expects every one of its members to be and to do their best every day. Performing work that is

“good enough” is not good enough. Employees should be proud of everything that goes out which has their name on it and the name of the company that they represent. This concept is an essential component of many of the other core values

- initiative, openness, trust, and teamwork. Striving to perform with the highest excellence along with these other core values will allow everyone to take ownership in everything they do.

2.1.6 In it iat ive

Initiative is doing what it takes to get the job done without waiting to be told.

It is being proactive in your approach to performing tasks. It also means to anticipate obstructions and take the appropriate action within your circle of influence[11] to avoid problems before they arise or before they become insurmountable. Everyone makes mistakes from time to time, but no one should be punished or feel ashamed for trying to get something accomplished. If an honest mistake is made in the name of being proactive, we as a company must learn from the mistake and move forward.

2.1.7 T e am w o rk

The concept of teamwork is important to a work environment. In today’s engineering environment, with increasingly complex requirements, it becomes necessary to work as a team. There are a number of reasons why teaming is important. On the most basic level, teaming helps build trust and reinforces integrity and excellence. Teams learn from each other and take advantage of the diversity of their members. Teaming also allows groups of individuals to accomplish more than they could otherwise do on their own. In this sense, a synergistic effect takes place where the whole is worth more than the sum of its individual parts.

Additionally, groups of teams can break down complex tasks into manageable pieces, and then on a higher level, those manageable pieces can be integrated together to successfully engineer complex and robust solutions that fulfill the system requirements.

By organizing the corporation this way and emphasizing teamwork, the core values of the company are employed at the most basic level within a small group of

peers who take initiative, build trust, respect and utilize each other’s diversity, share a high level of openness in listening to and trying new and innovative ideas, count on each other’s integrity and honesty, push each other to strive for excellence, take care of each other, and have fun. By teaming on the lowest levels of the company, employees will be able to put the core values into practice on a daily basis, thereby honing their technical skills as well as their ability to deal with each other in a variety of situations.

2.1.8 T a kin g C a re o f E a ch Ot h e r

The leadership in the company will be committed to providing for the employees a stable environment that encourages the development of both technical and non-technical skills as well as allowing for personal growth. Every employee will be able to develop a plan to take their career in the direction they choose.

Hiring a person means not only giving them a job, but also bringing them into your family. This includes making sure they can take care of their loved ones and allow them to grow as well. The leadership team is there to serve the employees and to provide them with the resources they need to do their jobs and take care of themselves and their families. Leadership will extend to the employees, same level of respect, concern and caring that they extend to the customers.

The concept of taking care of each other does not just apply to the leadership. It must exist with everyone in the company. The employees are expected to treat their co-workers with the same level of professionalism as they would with each customer. They should work to ensure that they are contributing to a positive work environment for themselves and each other. Occasional conflicts are bound to arise in the course of working together; these conflicts should be

taken care of at the lowest possible level and parties should approach each other in such a way that they first seek to understand the other party in the conflict before demanding to be understood and they should try to seek common ground in the conflict as a jumping point for resolving differences.

Taking care of each other does not just apply to employees as well. It includes the families of the employees. Employees should be there to help each other out in times of need. This is a philosophy shared by the United States

Military. When a military member cannot leave duty, other members of the unit will be there for the spouse and children. When a military member is away from his family for the holidays, other members of that unit will make sure the member is not alone.[12] It is in this type of environment, one of a family atmosphere, that the company is committed to for all of their employees.

2.1.9 Co m m u n it y I n vo lve m e nt & S o cia l C o ns cie n t io us n e s s

In 1886, the Supreme Court of the United States ruled, in Santa Clara

County v. Southern Pacific Railroad Company, that corporations are to be treated as

“persons” under the 14th Amendment to the Constitution of the United States.[13]

In light of this case, one could argue, that corporations have a responsibility not just to live up to the same social contract that we, as individuals, must live up to, but should go even further. Corporations do not exist in nature, they exist because we pass laws that allow them to exist, and they enjoy the advantages of those laws and of the 14th Amendment. So, with those advantages comes an even greater responsibility to contribute positively to the community at a local level, and to

society in at large. We do not believe that anything is gained by avoiding taking a stand on social issues.[14]

2.1.10 Fu n

Fun is an important part of what the company does. When hard work is expected, long hours from time to time are inevitable. The company will encourage and support an environment, not only where employees can have fun while at work, but also where the work itself is fun. In addition, the company is committed to supporting and encouraging employees, within the context of their teams, to take time for team building and having fun outside the confines of the workplace.

Employees are sometimes asked to spend larger amounts of their waking hours with their co-workers than with their own families. The work is serious and, at times, very stressful. It is incumbent upon those in leadership positions to support stress relief and create an environment where the employees want to come to work. This includes how project schedules are created and how budgets are allocated.

2.2 Vis io n

Having a vision gives meaning and purpose to our endeavors. It means that the work is for something that is not fleeting. One of the common mistakes that business organizations make is not having a meaningful vision. They set their goals to meet a deadline or to finish under a specified budget or to make a certain amount of money. These goals are empty and those that see their vision as getting a product ready in a set period of time or selling a certain number of units will not last long. In, The Art of Business: In The Footsteps of Giants, author, Dr. Raymond

Yeh refers to these companies as mechanical and lacking a “soul”. He states that the companies with “soul” are those that have essentially become living systems and had the “drive to create something beyond individual selfish desires”. As Dr.

Yeh states, “only those companies possessed of a soul, had any hope of longevity in the constantly changing business climate.”[15] As part of this concept, every member of the organization must keep in mind as they perform their daily tasks that their goal is not to balance an accounting book or complete a section of software code or place a certain number of orders with a vendor. Those are merely tasks that represent a higher purpose to meet the vision set out for the company.

Those tasks fit into a larger equation that helps achieve the vision defined by the company.

An example of misplaced vision lies in a system developed at a major defense industry company in 2002 and 2003. The system was a joint venture with a company that had an international customer. Originally awarded to a competitor who eventually passed on the project, this system was developed on an extremely short schedule. Because it was delivered early, earning the company a very large bonus, many viewed this project as a huge success. However, this project actually proved what could go wrong when a meaningful vision did not exist. Instead of the project leadership defining a clear and meaningful vision they focused on how quickly and inexpensively the project team could build the system. Team members were distrustful of leadership and morale was low because they were required to work long hours (an average of 60 to 70 hours a week) to meet the deadlines without being allowed to participate in the overall design, and thereby not having a sense of ownership of the system. As a result, the team created Factory and Site

Acceptance Test (FAT and SAT) plans that were very narrow in their focus and only showed a product that would pass the tests under perfect conditions. When other errors occurred in testing as a result of using the system under normal parameters, opening a problem report was highly discouraged if it would interfere with the FAT or SAT. The final result was a system that was signed off on by the customer after passing the SAT, but which has never been used by the customer since being fielded more than two years ago.

In order to provide a direction for the company, a vision that is both meaningful and living – one that can be modified over time to take into account a changing business environment – will be defined. This vision will guide the company and give purpose to the employees and help focus the energy of the employees upon making the company successful. The vision of Pilot eLog, Inc. is as follows:

To create and offer the best services for civil aviators to collect and access required information regarding flying, thereby allowing members of the civil aviation community to focus on their passion to fly.

2.2.1 W h o Do W e H ire

Who the company hires is an extremely important part of preserving our values. While those in entry-level and college graduate level positions are, to a certain extent, more or less a “clean slate” when it comes to holding particular beliefs about the workplace, it is important to ensure that their attitude is a good fit for the company. They must either have beliefs that are compatible with the company’s core values, or be open enough to adapt to the corporate philosophy. In the case of experienced professionals who are new to the company, it is important

that the company hires quality people whose personal values are compatible with those of the company and who can put those values into practice - whether they are an individual contributor or a formal leader - so that they can serve as positive examples for junior employees to follow. An individual can be trained to gain the technical skills that are required to perform their jobs, therefore, the exact technical skills a person possesses are less important, when hiring someone, than whether or not their values are compatible with those of the company.

2.3 P u rpo s e

Purpose describes how a company will fulfill its vision. The purpose serves as a guide, along with the core values, to keep the company directed toward achieving its vision. While most companies define a vision, a purpose, and values or VPV[16], they become meaningless to many. They do not become a part of the culture and employees never use the values as a best practice. This makes it more difficult to stay focused on the real goals of the company. The blame for this lies with the leadership of a company. They either create these VPVs because that is what most companies do and the VPVs end up in the back of the annual reports to the stockholders[17], or the leadership for these companies push the values, make sure everyone knows what they are, but then do not provide real support to employees who are trying to follow these values. Part of the challenge for any company is for the VPV to remain a very real thing that can be demonstrated and measured. For Pilot eLog, inc. the purpose is:

To offer reliable products and services that free individuals to pursue their passion. To create a stable and happy environment that allows our employees to be productive, grow both personally and professionally, and become leaders in their

field. To maintain a positive impact on the local community and on society as a whole for as long as the company exists.

2.4 E n gin e e rin g M e t h o do lo gie s

A methodology is a group of ideals, tools, and processes used to build a set of artifacts known collectively as an engineering system.[18] Specifically, for software there are a number of popular methodologies including scrum, waterfall, iterative, RAD (Rapid Application Development), prototyping, etc. There are advantages and disadvantages to each of these methodologies; however, many of the methodologies in practice today are merely modifications of the above methodologies. Because of this we can learn from each of them and derive our own processes. In the context of a corporation that specializes in software development, we can further break down our engineering methodologies into two specific groups, a software engineering methodology and a software maintenance methodology.

2.4.1 S o ft w a re E n gin e e rin g M e t h o do lo gy

Software engineering methodology is a set of processes by which software is developed. Like engineering standards, the processes should be simple to understand, such that they are easy to implement and easy to enforce. The overlying idea behind the methodology is to make it as simple as possible, while still meeting a few requirements. For example, the processes should be easy to learn and follow, they should be repeatable, and they should be complete enough so that any developer can take over, and by reviewing the associated documents, be able to understand the system and write code for it.

Figure 1: Software Development Process

2 .4 .1 .1 De f in e S co pe

Defining the scope is the first part of the process. This step is important because it helps define what and how many resources are going to be needed for the project. The scope is used as a reference for the project team. For every new requirement and design element, team members should ask, “Does this fall within the scope of the project?” If a new requirement arises, that is the first question that should be asked. It is from this phase that a Statement of Work document is created and reviewed and approved by the project stakeholders. It is at this point in the project that a project schedule is created.

2 .4 .1 .2 Re qu ire m e n ts Ga t h e rin g & A n a l y s is

Once the scope is defined, requirements can be gathered and analyzed. This step requires analysts to begin to understand exactly what the customer needs and how the software will help them fulfill that need. Engineers need, not only to understand the customer’s needs, but how the customer does business. Every requirement should fall within the scope. Out of this phase, a Requirements

Specification is created and reviewed and approved by the project’s stakeholders.

When the Requirements Specification is approved, it becomes base lined and any changes to the requirements must pass a formal review process that takes into account cost vs. benefit in terms of dollars and time against the schedule.

Additionally, the formal test plan and test cases begin to be developed out of this phase. The formal test plan and test cases should be a reflection of the

Requirements Specification.

2 .4 .1 .3 P re lim in a ry De s ign

When the requirements have been approved, a preliminary design can begin to be developed. In actuality, this can begin as requirements are gathered and analyzed and any changes. This is where proof of concept code might be developed, it is where use cases are created and from them classes, behaviors, and interacts take shape. It is where prototyping might occur and where the developers and analysts begin to create the user interface. In this phase, the draft design documents are prepared for the stakeholders for review and sample screen captures are shown to the end users for feedback on the user interface. In addition to the design, this phase is where an implementation plan begins to be developed.

The formal release instructions will continue to be developed through the testing phase, if necessary.

2 .4 .1 .4 C rit ica l De s ign

After a Preliminary Design Review takes place and approvals are obtained, the Critical Design Phase begins. This is where issues that were posed in the preliminary design are addressed, the user interface is finalized, and the design documentation is finalized, including a matrix that shows how each design aspect ties in with the requirements. This is done to ensure that no unnecessary design elements are in the system and that we do not experience “requirements creep”.

During the critical design review, stakeholders should ensure that each aspect of the design is justified and all requirements are met.

2 .4 .1 .5 De ve lo pm e n t a n d C o din g

This phase can begin with developers constructing framework and proof of concept code during the Preliminary and Critical Design phases. However, any code developed before the Critical Design Review is subject to change. Code in this phase should be peer reviewed and test plans for unit testing should be developed and carried out. Teams are charged with the responsibility to ensure that their code is unit tested and that testing is properly documented. Team leads are responsible for signing off on the testing for their code. The Development and

Coding phase is complete when all the requirements are met and the system passes unit testing.

2 .4 .1 .6 Fo rm a l T es t in g

After the Development and Coding phase is completed, the Formal Testing phase begins. The Formal Test Plan and Test Cases should be completed and approved by stakeholders. The review process for this is less formal and can be done via email or conference meeting. The Test Plan and Test Cases document should be a reflection of the Requirement Specification, but if other errors are identified, they should be included in error reports along with the functionality defined by the Requirements Specification.

The formal testing team should be independent of the development team.

The team leads of each should be peers that report to a higher level of management. This is done to ensure that the development team does not inappropriately influence the testing team. At this point in the project, the testing team should be in close communication with the development team to ensure that identified problems are understood and solutions are found. This phase is an

iterative process. When errors are found, they are passed to the development team for analysis and repair and unit testing, and then returned to the formal testing team for re-testing. When this phase is complete the results are added to the formal testing documents and along with the formal release instructions, are reviewed and approved by each stakeholder.

2 .4 .1 .7 Fo rm a l Re le a s e

When the system has been reviewed and approved for release the system can be implemented and put into production. After implementation, there is a short window where the development team will handle any problems that arise. If the system has made it through this window with no or little problems, the system formally passes into maintenance mode. In some cases, projects will have a period of Beta Testing. It is left to the discretion of the team to decide if a beta test is warranted for their project.

2.4.2 S o ft w a re M a in t e n a n ce M et h o do lo gy

Just as it is important to have a defined process for software development, it is equally important to have a defined process for software maintenance. In both cases the defined process helps prevent ambiguity in the creation and repair of software, and allows for the collection of metrics in order to track the effectiveness, and therefore, the cost of performing development and maintenance. From there, weaknesses can be found and corrected in order to maximize profits.

2 .4 .2 .1 E n h a n ce m e nt Re qu e s t P ro ce ss

The maintenance process is based on identified problems or enhancements.

First, the change is identified and a Change Request created. The next step is to

identify whether the issue is an enhancement to already functioning software, or an error condition. If the change request is an enhancement, it then goes to a Change

Review Board (CRB) comprised of representatives of each area of the information technology team (systems administration, database administration, software development, etc), which convenes at regular intervals (perhaps weekly or biweekly), who will assess the cost-benefit of implementing the change request, as well as the priority of the change request. After the CRB completes its task, the change request then gets scheduled and assigned appropriately to a software development team. At this point, the change request goes through a mini-cycle of the software development process (described in section 2.4.1). Once the software development process has been completed, the enhancement is then rolled into the production environment and the change request is completed and closed.

2 .4 .2 .2 E rro r Re qu e s t P ro ce ss

The maintenance process is slightly different in the case of an error condition. When the change request is received and determined to be an error in the software, the next step is to determine if the issue is critical or not. In order to be a critical error, the issue must be customer facing, and have no work-around. If the issue is a critical error, it is then sent to the members of the CRB for immediate review and comment. At this point, a determination is made whether to maintain the critical status of the error or to lower the severity of the issue. If the CRB members lower the issue in severity, it then follows the same process as described for an enhancement. If, however, the CRB members agree that the issue is critical in severity, it is immediately assigned to a development team where it goes through the software development process. When a solution has been created and

tested, a patch is implemented into production and the Change Request is closed.

The turn-around for a critical error should be 24 hours. If the error is not critical, the length of time to complete the request is based on a determination by the CRB as to the priority. This is dependent upon a number of factors, including non- critical errors and enhancements already approved and scheduled for implementation, and the current workload of the software development group.

Figure 2: Software Maintenance Process

2.5 E n gin e e rin g S t a n da rds a n d Gu i d e lin e s

Standards and guidelines are an important part of the engineering process.

Guidelines are not as stringent as standards. They are some loose rules to live by when performing work, but are flexible depending on the particular situation.

Standards are a defined set of rules published to ensure that a product or process fulfills its purpose. Defined standards help resolve issues of product compatibility, simplify development, and reduce inefficiencies related to non-value-added costs.

In addition they help with integration and interoperability between two systems.[19] For the corporation, the focus will be on simple and easy to follow standards. As the corporation grows, it will be necessary to further define the standards and to create additional standards to comply with the requirements of other entities such as the Unites States Government. For the start of this corporation we will concentrate on some simple documentation standards, coding standards, and GUI guidelines.

2.5.1 Do cu m e n t at io n S t a n da rds

Documentation standards ensure quality and repeatability in the software process. They also help explain the intent of the system and help mitigate loss of productivity due to employee turnover. It is important to note that the documentation can be in any format (electronic or hard). The documents included in the standard are:

• Statement of Work: This document contains the overview of the system

and scope of work. It lists the expected resources required and an overall

timeframe for completion.

• Requirements Specification: This document lists the complete system and

software requirements for functionality and performance. It also contains

any interface requirements.

• Design Description: Includes the software design description. The

software design includes applicable use cases, class models, database

schema and object models, any APIs developed that can go into a

software library, and finally a matrix that maps how design elements in

the system fulfill the requirements. In addition, this document should

include the operational concept of the system from the user’s perspective.

• Test Plan and Test Cases document: This document describes how

testing will occur and what specific test cases will be performed. Each

test case will indicate the requirement to which it is mapped.

• Implementation Plan: This document describes how the system will be

rolled into production.

• User’s Manual: This document will help the user understand how to use

the system. This document can be an online manual or the help provided

for the system.

2.5.2 S o ft w a re C o din g S t a n da rds

One of the biggest problems with coding of software solutions is lack of adherence to coding standards. Often when developers learn a language, they get used to writing code in their own style and have a difficult time breaking old habits.

Another reason that standards are not adhered to is, when they are developed, the standards are often so restrictive and lengthy that they actually hinder the developer. Since developers are often asked to “hit the ground running” to complete code on a short project schedule under intense pressure, they sometimes cut corners with software coding standards. Finally, the standards that are developed are not made a priority by the leadership, often resulting in not paying attention to the way the code is written as long as it seems to work.

There are a number of reasons why coding standards are important.

Development and adherence to coding standards makes the code easier to understand by the engineers. In the event that the original developer is otherwise occupied or is no longer part of the team that is responsible for the code, it will be much easier for another developer to take over the tasks associated with that code.

After the code is released, should a problem arise, support personnel will have a much easier time isolating the problem and finding a solution. Finally, when coding standards are followed, it makes reviewing the code a much easier task to perform for engineers.

There are a few basic guidelines that coding standards should follow, but beyond that, they should not be too restrictive. Many of the guidelines are based on a common sense approach. First, the code should be readable. Just like in formal writing one separates ideas into paragraphs and uses punctuation to help the reader, code should be divided into blocks and spaced out in such a way that it is easier to read by other engineers. Not every line of code needs commenting, however, logically grouped blocks of code should have comments associated with

them that give an indication of the intent of that code. Software coding standards can be found in Appendix B.

2.5.3 GU I I m ple m e n t at io n Fra m e w o rk

One of the problems with GUIs is that they tend to not take into account the user. In general, there is not a strict standard for GUIs. One should follow the guidelines put forth for the platform on which the application is being developed.

For example, Apple Computer and Microsoft both provide GUI guidelines for developers designing for their respective operating systems. If the application is web based, then a different set of rules applies. The customer is not necessarily limited to a single platform. If this is the case, one can choose a set of guidelines and adapt them for use in specific situations.

Selecting a set of guidelines is only one aspect of developing a useful GUI structure. The other aspect, which is much more important, involves creating a useful interface for the customer. The goal of software is to make a customer’s tasks easier to complete, yet often the GUI acts as an encumbrance to the customer. With this in mind, a framework for the implementation of a GUI is important to define. Although, the GUI development process is a part of the software development process, there is a fundamental difference in the philosophy between software and GUI development. Since the GUI is the way that humans interact with the system, it is important that its development be somewhat “user- centric” rather than “problem-centric”.[20] Because of this, we can proceed to develop a five-step process for developing GUIs. First, find out what the customer is already using or what their requirements are for the interface.[21] This process is part of the requirements gathering and analysis stage of the software

development process. Second, study the findings of the of the requirements and estimate the effort to build a GUI that meets the customer requirements.[22] This step is also part of the requirements gathering and analysis phase. Third, conduct follow up meetings with the customer to resolve questions about the GUI and solidify the effort required to meet the requirement.[23] One of the important outcomes of this meeting is to set customer expectations based on the schedule and cost of the GUI requirements. At this point in the framework, the GUI requirements can be base lined and the development team can work on finalizing the interface. This part of the process is folded into the preliminary design portion of the software development process. Fourth, when the customer has provided the feedback necessary to finalize the interface, the development team can implement the GUI and tie it into the functionality of the system.[24] Any changes that need to be made fall into the category of a new requirement and under the heading of a baseline change request. This means an additional iteration of the software development process must take place with regard to the new requirement, impacting the project schedule and cost. Lastly, a final review of the agreed upon

GUI implementation takes place.[25] The customer will approve this step as part of the critical design review in the software development process. Again, if changes need to occur in the GUI, a baseline change request is once again required.

CH A P T E R III TI MI N G

3.1 Gro w t h S t rat e gy

In order for a company to survive in the long term, it must be able to grow and change over time. For a company that provides a web based subscription service, staying current with technology, regularly increasing its customer base, and influencing the rules that govern the product or service provided are all important parts of its growth strategy.

3.1.1 St a yin g C u rre n t w it h T e ch n o lo gy

Staying current with technology is an important aspect of remaining relevant in your chosen industry. It means to stay on top of new and better ways to provide solutions for your products and services in order to produce the least painful user experience. It plays into the core value, Openness, by empowering every employee to explore new and better technologies. These new technologies should have the end goal of improving the customer experience, which can mean anything, including improving security, improving performance, improving the interface, cutting development cycles, etc. By staying current with technology, the company can remain competitive with any old and new competitors in the market place.

3.1.2 In cre a s in g C u s t o me r Ba s e

Companies are defined by their ability to grow. In the case of a service- based company, this means increasing the customer base. For this company, the initial market is the population of civil aviators. As of December 31, 2004 the total number of active private pilots was 235,994 and the number of active student pilots

was 87,910 for a total of 323,904.[26] The FAA estimates that the student population will increase at a rate of 1.8% per year and the private population will increase 1.2% per year from 2005-2016.[27] If goal of 1% of the student and private pilot population in 2006 is chosen, and increased by 1% per year, the earnings will be projected to close to $2 million dollars per year by 2010.

Figure 3: Earnings Projections

Just for fun, to see what it would look like at 100% market penetration, the revenue for a $5 per month fee for all student and private pilots was determined on the chart below. In 2010, the total revenue tops out at over $20 million dollars annually.

Figure 4: Potential Earning for 100% of Market

The numbers on the above chart (Figure 4) and in the previous chart (Figure

3) are based on the FAA projections for new pilots from 2005-2016. There are a number of factors that could affect the accuracy of the FAA projections, such as the increased price of fuel -- thus increasing all costs associated with flying, not just re- fueling costs. Additionally, the health of our society is falling because of a number of factors, making it more difficult to be medically certified to fly. Also, more stringent rules about who is allowed to get a pilot certificate are in effect as a result of the terrorist attacks on September 11, 2001. Despite these factors, one thing that may increase the number of active pilots is the creation of a new class of pilot, the Sport Pilot. This certification, added recently by the FAA, requires less training and makes a medical certification easier to obtain, by adding restrictions that private pilots do not have.

3.2 Co rpo ra t e Ro a dm a p

For any company, it is a good idea to have a strategy for how to achieve thier vision. A company has to find its way to success. This is done by creating a corporate roadmap. In order to create an effective roadmap, three things known: the corporate vision, the incremental goals, and a well defined competitive space.

Figure 5: Corporate Roadmap

CH A P T E R I V LE VE RA GI N G

4.1 C re at in g A dva n t a ge

Creating advantage is an important aspect of being successful in a technical market. This is where the idea of leverage comes into play. Leverage is the ability

“to achieve maximum effect with minimum effort.”[29] The three main areas that can be immediately exploited to leverage resources are technology, corporate infrastructure, and external resources.

4.2 T e ch n o lo gy

Technology is an area where great advantage can be gained at very little cost. Although there are many costly technology solutions and development tools, with the open source movement, there is a huge exchange of information for developing and creating solutions. There are many tools available at no cost or relatively little cost.

4.2.1 S o ft w a re & S o ft w a re De ve lo pm e nt T o o ls

• Relational Database systems: MySQL, PostgreSQL.

• Programming Languages: Java, PHP, C++.

• Interactive Development Environments: Netbeans.

• Operating Systems: Linux, FreeBSD, OpenBSD.

• Webserver Software: Apache Webserver

• Build Scripting Software: Ant.

• Configuration Management: CVS, RCS, PRCS, Aegis.

• Web Browsers: FireFox, Opera, Netscape.

4.2.2 Bu s in e ss S u ppo rt S o f t w a re

• Office Automation Suites: Microsoft Office, OpenOffice, StarOffice.

• Project Scheduling: Microsoft Project, OpenSched.

• Modeling Software: Open SystemC Initiative, Gaphor, Microsoft Visio.

4.2.3 H a rdw a re

• Sign on with Hosting service to provide hardware.

• Build a system: Intel or AMD processors, basic motherboard, raid, hard disk drive, optical drive.

• Sign on with rack space provider or share rack space with another business partner.

4.3 Co rpo ra t e I n f ra st ru ct u re

Part of leveraging is building an infrastructure that allows employees to act in an unimpeded way in the conduct of its business. The concepts put forth in

Chapter 2, describe how the infrastructure will enable the corporate team to be as productive as possible by promoting openness, building teamwork, honoring and utilizing diversity, building processes that enable the efficient engineering of the company’s products, and having a leadership team that promotes an environment in which the core values become a part of the corporate culture.

4.4 T a kin g a dva n t a ge o f E x t e rn a l re so u rce s

Just as there are internal actions that allow companies to exploit resources to their fullest, there are also many external resources that allow companies to increase the efficiency at running their business. Among these are accounting and payroll services, advertising and payment solutions.

4.4.1 On lin e a cco u n t in g a n d P a yro ll s e rvice s

• Accounting and Payroll: Intuit Payroll services, Intuit Quickbooks Online, Automated Data Processing (ADP), Paychex.

4.4.2 A dve rt is in g

• Partner agreements: Aircraft manufacturers (Cessna, Diamond Air, etc),

Flight Schools, FBOs.

• Search Engines: Google, Yahoo.

• Industry Related Publications and Websites: AOPA Pilot Magazine,

Kitplanes Magazine, AVWeb.com, Flying Magazine, etc.

4.4.3 On lin e P a ym e n t S o lut io n s

• Payment Services: Online services for credit card processing, PayPal.

• Payment Products: COTS eCommerce Software, Server Host provided eCommerce packages.

CH A P T E R V M A ST E RY

5.1 Bu ildin g C o rpo ra t e K n o w le dge

There are three aspects to building knowledge within the context of the company that will be focused on in this chapter. They are: the concept of culture, infrastructure, and technical and non-technical learning.[30]

5.2 T ra in in g

An important part of extending the abilities of the employees is training, not only formally, but also informally, through example and being given opportunities to excel while under the instruction of an experienced mentor. Everyone at the company should have the attitude that they will take the job of a more senior employee and that a more junior employee will one day take their job.[31]

Redundancy is important and retaining sole ownership of “corporate knowledge” is unacceptable. It is essential for those in leadership positions to promote an environment where employees do not feel the need to create “job security” for themselves.

5.2.1 T e ch n ica l T ra in in g

Members of the technical team will be expected and encouraged to attend training to learn new skills and improve upon existing skills. Before continuing, it is important to note that that technical means any training pertaining to one’s job. It is not exclusive to those in ”highly technical” positions. This includes serving as trainers for junior employees.[32] An important aspect of training is the company

fully supporting the training efforts of the employee population by providing adequate funding and scheduling for formal training.

5.2.2 N o n -T e ch n ica l T ra in in g

Non-technical training for all employees is just as important as technical mastery of skills. This includes outside self-improvement such as college education. However, self-improvement does not just include college. For example, if an employee wishes to learn how to become a private pilot or a scuba diver, there will be reimbursement available, on some level, for that type of training.

Non-technical training also includes formal and non-formal training in skills that allow employees to interact at a higher level with business partners, customers, and each other, and those in their personal lives. This may include training to increase business acumen, communication, diversity, teambuilding, and leadership (discussed in Chapter 6). Again, non-formal training includes passing down habits and knowledge about non-technical skills from more experienced personnel.

Figure 6: Evolution of Mastery

CH A P T E R VI LE A DE RS H I P

6.1 De f in it io n

Leadership is difficult to define. It is one of those things that many people have trouble verbalizing, but know when they see it. Retired U.S. Army General

Wesley Clark defines one aspect thusly:

“From my days in the Little Rock Boys and Girls Club and all through my years at West Point and the Army, I learned and taught that leadership means lifting people up; challenging them to push themselves to succeed where they before thought success was out of reach. That philosophy was captured well by our Army motto, "Be All You Can Be," which also means helping others to be all they can be. What we need to do as individuals and a party is to stand up and speak out to create equal opportunity for economic success. To treat others the way we want to be treated. To reach out and help those who are in pain. Most importantly, leadership means calling on others to do all these things too.”[33]

Indeed, the military is a place where one can learn about leadership. The military is, in fact, about leadership. One of the goals of the military, as it pertains to its personnel, is to teach everyone to be a leader.[34] Certainly, in the corporate environment, lives are not at stake, but the principles expressed by

General Clark still apply.

6.2 T h e Dif f e re n ce be t w e e n L e a din g a n d M a n a gin g

There is a fundamental difference between managing and leading. Leading is the act of influencing people to willingly perform together to achieve a goal.

Managing is more functional, whereas leading is relational.[35] Although good

managers may be considered “the brains” of any business by establishing systems, and by creating rules and procedures; management is not about people.[36] The key mistake often made in corporations is that they identify and train people to be managers. While these corporations may offer formal training in leadership, by the time the employee is sent to such courses, it is too late because the idea of leadership is not a cultivated part of the work environment. What ultimately happens is that businesses hire and identify employees for management – people they believe are technically capable of managing budgets and project schedules – and then expect them to lead people. Corporations that have a “manager- centered” mindset tend to have less success with projects -- and higher employee attrition -- because they do not purposefully identify and hire leaders.

6.3 De ve lo pin g L e a de rs

A discussion about leadership and the differences between leaders and managers would be meaningless if a discussion of developing leaders were not engaged in. Corporations, for the most part do not do a very good job of developing leaders. Certainly, there are good leaders found in corporations, but it is rare in today’s environment to find leaders that are developed by a corporation.

However, there is a large organization where leadership is encouraged and developed. That organization is the United States military.

Leadership is taught from the first day a recruit arrives at basic training.[37]

They begin by first learning how to follow, and by emulating positive examples of their superiors. They gain experience by being given leadership responsibilities once they have demonstrated the ability to understand the implications of that leadership. In the Air Force, a typical Airman will follow this pattern of leadership

development and sometime after the individual gains the rank of Senior Airman (E-

4), they are sent to the first level of Enlisted Professional Military Education (EPME), known as Airman Leadership School (ALS). The purpose, objective, and philosophy of this training is as follows for the Leadership School located at Hurlburt Field near

Fort Walton Beach, Florida:

“The purpose of Enlisted Professional Military Education (EPME) as stated in the USAF Enlisted PME Procedural Guidance is: ‘…to provide enlisted personnel with the skills and knowledge to make sound decisions in progressively more demanding leadership positions within the national security environment and to strengthen their understanding of and commitment to the profession of arms.’

The objective of the Hurlburt Field Airman Leadership School is to prepare senior airmen for supervisory duties and foster a commitment to the Profession of Arms. AFI 36-2301, Professional Military Education, and the USAF Enlisted Professional Military Education Procedural Guidance govern the school. The Airman Leadership School is often the first step in a three-tiered program followed by the NCO Academy and the Senior NCO Academy.

Our philosophy is quite simple. We believe in the educational concept that learning information and skills requires real usefulness only if an effort has been made to understand why. The curriculum has been designed in such a way that the knowledge gained makes sense and is usable by the receiver. The learning process is personalized and linked to the real world in which the individuals manage their personal resources. This approach dictates that all programs be student centered.”[38]

From the above statements, it is fairly easy to discern that the military is serious about leadership. For the purposes of a corporation there is not a need be

as extreme as the military with the development of leadership. However, the military can be used as a model by which the company can create some leadership development guidelines.

The corporation having leadership guidelines is fundamental. The guidelines allow the corporation to establish an environment where leadership is valued and the act of developing them helps set expectations. The first and simplest guideline is to set good examples for others to follow. It is also important to communicate to the employees that even the most junior employee can demonstrate leadership everyday by exemplifying the core values. This serves to motivate an employee’s peer level co-workers to follow that example. In addition, leaders should practice situational leadership theory with their subordinates.[39] Situational leadership is a belief “that presumes that different leadership styles are better in different situations, and that leaders must be flexible enough to adapt their style to the situation they are in.”[40] Situational leadership along with a goal of creating positive outcomes for all parties so that success can be shared is the most desirable state. Finally, it is important for employees to be sent to formal leadership training so that the concepts can formalized in the classroom and then put in to practical use. By taking a proactive approach to developing leaders, a corporation can ensure it keeps a strong foundation to preserve its core values and remain viable in the long term.

CH A P T E R VII TH E P RODU C T

7.1 St a te m e n t o f W o rk

7.1.1 P ro j e ct Ove rvie w

This project is to develop an online (web-based) system by which customers (student and private pilots) can store their flight log (as required by the FAA).

7 .1 .1 .1 Bu s in e ss N e e ds

The business need for this project is that it will be the core software for a new company.

7 .1 .1 .2 C us to m e r P ro f ile

The customers are comprised of active student and private pilots who will benefit from being able to access their flight logs via the Internet and/or will benefit from having an electronic backup of their manual flight log.

7 .1 .1 .3 C us to m e r Go a ls

The primary goal of the project is to provide a reliable storage place for our customer’s data that can be accessed from anywhere that the customer has access to the Internet.

7.1.2 P re lim in a ry Re qu ire m e n ts

Customers shall have the ability to securely login to a web-based application that will allow for the entry, removal and modification of data related to a pilot’s flight logbook. That data shall be permanently stored in a database and be retrievable for display and printing in reports. 7 .1 .2 .1 S co pe o f W o rk

• Collect and analyze requirements for a system (described in Section 7.1.1).

• Design, code, and document a system around the requirements. • Build Test plan and test cases for the system from the requirements.

• Develop an implementation plan and implement the system to a projection environment.

7 .1 .2 .2 C rit ica l C o n st ra in ts

• System must operate in a web-based environment. • System must handle the web hosting company’s constraints. • System must be available 24 by 7.

7 .1 .2 .3 Fu n ct io n a l Re qu ire m e n t s

• Customers shall have the ability to create an account and login securely to that account via the Internet.

• Customers shall be able to add, modify, and delete flight log related data. • Customers shall have the ability to display and print records in a report format.

7 .1 .2 .4 P ro j e ct De live ra ble s

• Statement of Work and Review. • Requirements Specification and Requirements Review. • Design Document and Preliminary Design Review. • Design Document and Critical Design Review. • Test Plan & Test Cases Document and Review. • Testing Report (Test Plan & Test Cases Document) and Post-Test Review. • Implementation Plan and Implementation Plan Review. • Release to production environment.

7 .1 .2 .5 St a n da rds

The system shall use established Pilot eLog documentation standards (Appendix A) and established Pilot eLog coding standards (Appendix B). 7 .1 .2 .6 T a rget E n viro n m e n t

• The initial release shall function on a Linux-based system at a host provider.

• Subsequent releases shall function on a Linux or FreeBSD server hosted by Pilot eLog.

• The database shall be PostgreSQL. • The web server shall be Apache web server.

7 .1 .2 .7 S u m m a ry o f C us t om e r P rio rit ie s a n d E x pe ct a t io ns

7 .1 .2 .8 S e cu rit y

The application shall utilize industry accepted standard Internet security protocols (SSL). 7.1.3 P ro j e ct S ch e du le

Figure 7: System Project Schedule

7.1.4 De ve lo pm e n t E n viro n m e nt

This project shall be written in PHP and HTML. The development environment is flexible, but shall be developed on systems loaded with Mac OS X 10.4 (Tiger).

7.1.5 Ve rs io n H ist o ry

Version Date Changes Made 1.0 10/10/2005 Initial Release

7.2 Re qu ire m e n ts S pe cif i ca t io n

7.2.1 S yst e m Ove rvie w

Refer to Statement of Work (Section 7.1).

7.2.2 Re f e re n ce Do cu m e n t s

7 .2 .2 .1 P ro j e ct Do cu m e n t s

• Statement of Work • Design Document • Test Plan and Test Cases Document • Implementation Plan

7 .2 .2 .2 Ot h e r Do cu m e n ts

• FAA Certification: Pilots, Flight Instructors, and Ground Instructors (CFR Part 61; Reg. §61.51, Pilot logbooks.) • Jeppesen Pilot Logbook JS506048

7.2.3 Re qu ire m e n ts

The requirements for the system fall into three categories detailed below. These categories are hardware requirements, software requirements, and interface requirements.

7 .2 .3 .1 H a rdw a re

The version 1 of the system shall run on a hosted server.

7.2.3.1.1 The system shall run on hardware that supports a Unix-based operating system.

7.2.3.1.2 The network shall support 100 GB/month data transfer.

7.2.3.1.3 Hard disk storage capacity for database and application must be 4 GB.

Later versions of the system shall run on a dedicated server.

7.2.3.1.4 The system shall support a minimum of 300 GB/month of data transfer.

7.2.3.1.5 The system shall support a minimum of 500 static web pages/minute and a minimum of 100 dynamic web pages/minute.

7.2.3.1.6 The system shall support a raid with a minimum of 2 disks.

7.2.3.1.7 The system shall support a minimum of 100GB of raid storage.

7.2.3.1.8 The system shall have a minimum of 512 MB of memory; minimum of 2 GHz CPU; and a minimum of 100 Base-T network interface.

7.2.3.1.9 The system shall have an optical disk drive.

7 .2 .3 .2 S o ft w a re

7.2.3.2.1 The application shall have a secure login.

7.2.3.2.2 The application shall, after successful login, display a view of the user’s logbook information.

7.2.3.2.3 The user shall be allowed to select a record from the logbook to modify or delete.

7.2.3.2.4 The application shall provide a method of creating new logbook records.

7.2.3.2.5 The application shall provide a method of maintaining (create, update, delete) a list of air aircraft.

7.2.3.2.6 The application shall provide a method to display a report of their flight summary, which contains the number of hours of flight in the various aircraft types.

7.2.3.2.7 The application shall provide a method to display a report of flight hours by aircraft type showing the various types of flight (PIC, Dual, Solo, etc).

7.2.3.2.8 The application shall provide a method to display a report of flight hours by specific aircraft showing the various types of flight (PIC, Dual, Solo, etc).

7.2.3.2.9 The application shall provide a method of maintain user profile data including username and password.

7.2.3.2.10 The application shall provide a method of maintaining flight certifications.

7.2.3.2.11 The application shall provide a method of maintaining flight ratings.

7.2.3.2.12 The application shall provide a method of maintaining flight proficiencies.

7.2.3.2.13 The application shall provide a method of maintaining medical certifications.

7.2.3.2.14 Data Requirements See (Figure 8) Below

7.2.3.2.15 The application shall provide access to all GUI displays from navigation menu on left side of page.

7.2.3.2.16 .The application shall provide a method of printing the logbook.

Figure 8: Data Requirement Table

7 .2 .3 .3 In t e rf a ce

7.2.3.3.1 The application shall provide a secure login.

7.2.3.3.2 The application shall be accessed via the Internet through a web browser.

7.2.3.3.3 The application shall provide a left side navigation menu that will be displayed the entire time the user is logged in.

7.2.3.3.4 The application shall put related functionality that is too extensive for a single screen interface in tab form.

7.2.3.3.5 All mouse driven events shall be links on the screen.

7.2.3.3.6 Username and logout link shall be displayed in the upper right corner of the GUI and be visible for the user’s entire session.

7.2.3.3.7 “Home”, “Help”, and “Contact” links shall be displayed above the username and logout links and be visible for the user’s entire session.

7.2.4 N ot e s

7 .2 .4 .1 De f in it io ns U se d in t h is Do cu m e nt

None.

7 .2 .4 .2 A bbre via t io n s Us e d in t h is Do cu m e nt

None.

7.2.5 Ve rs io n H ist o ry

Version Date Changes Made 1.0 10/10/2005 Initial Release

7.3 De s ign Do cu m e n t

7.3.1 S co pe

To create a system that will allow customers to create and edit and print pilot logbook(s) that is accessible from the Internet. The logbook should serve as a safe repository for important flight log information.

7.3.2 De s ign C o n st ra in ts

• System must operate in a web-based environment.

• System must handle the web hosting company’s constraints. • System must be available 24 by 7.

7.3.3 De s ign A pp ro a ch

This system will be designed to be as componentized as possible by creating a core set of functionality that is common to any automated logbook and then building configuration tables that the system will read to know what and where to display on the GUI and know what and where to store the data.

7.3.4 T o p L e ve l C o m po n e n t I de n t if icat io n

7 .3 .4 .1 Fu n ct io n s of M a j o r C o m po n e nt s

7.3.4.1.1 Login: Allow access to the system.

7.3.4.1.2 Add/edit user profile: to create or update user information.

7.3.4.1.3 Display flight log: shows user what entries are in the flight log.

7.3.4.1.4 Display reports: shows user their hours by various different criteria, such as, by aircraft, by aircraft type, etc.

7.3.4.1.5 Print flight log: Print the contents of the flight log.

7.3.4.1.6 Add/edit/delete logbook entry: To create and update entries to the pilot’s logbook and to delete erroneous entries.

7.3.4.1.7 Add/edit aircraft: Create a list of aircraft for use in the flight logbook.

7.3.4.1.8 Add/edit pilot certificates: create records for the pilot’s certificates.

7.3.4.1.9 Add/edit pilot ratings: create records for the various ratings the pilot can obtain (such as instrument rating).

7.3.4.1.10 Add/edit flight proficiency: create records for the various proficiencies the pilot can obtain.

7.3.4.1.11 Add/edit medical certificates: create records for medical certificates.

7 .3 .4 .2 Da t a Flo w

The data that will flow between the user (Pilot) and the system will be requests and responses from system. Also, user data will be sent via the GUI interface and stored in the database (shown in Figure 9 below as data store).

Figure 9: Data Flow Diagram

7 .3 .4 .3 Fu n ct io n C o nt ro l

None.

7 .3 .4 .4 Fu n ct io n a l M a ppin g

Figure 10: Functional Requirement Traceability

7.3.5 E xt e rn a l I nt e rf a ce s

None.

7.3.6 De t a ile d De s ign

7 .3 .6 .1 De s ign S t a n da rds

• FAA Certification: Pilots, Flight Instructors, and Ground Instructors (CFR Part 61; Reg. §61.51, Pilot logbooks.) • Jeppesen Pilot Logbook JS506048 • GUI Guidelines, coding standards developed by Pilot eLog.

7 .3 .6 .2 Co m po n e n t De t a ile d De s ign

Use Cases

7.3.6.2.1 Login

• Scenario: User logs into Pilot eLog.

• Pre-Conditions: User has active account on system.

• Post-Conditions: User is granted access and view logbook screen is displayed.

• Actors: User, database

7.3.6.2.2 Display Logbook

• Scenario: Logbook is displayed to user.

• Pre-Conditions: user has successfully logged in.

• Post-Conditions: the logbook entries are displayed on GUI.

• Actors: User.

7.3.6.2.3 Edit User Profile

• Scenario: User edits user profile.

• Pre-Conditions: None.

• Post-Conditions: User (new or existing) saves changes to user profile.

• Actors: User, database.

7.3.6.2.4 Edit Aircraft

• Scenario: User edits aircraft in the system.

• Pre-Conditions: User must be logged in.

• Post-Conditions: Aircraft is available to use in logbook entry.

• Actors: User, database.

7.3.6.2.5 Display Report

• Scenario: User clicks on a report on the navigation menu.

• Pre-Conditions: User must be logged in. User must have logbook entries. User must have aircraft records.

• Post-Conditions: Report is displayed on the GUI.

• Actors: User, database.

7.3.6.2.6 Edit Logbook Entry

• Scenario: User clicks on add/edit entry on the navigation menu.

• Pre-Conditions: user must be logged in. User must have aircraft records.

• Post-Conditions: Logbook entry is saved to database. View logbook entries displays logbook entry edited.

• Actors: User, database

7.3.6.2.7 Print Logbook

• Scenario: User clicks on print logbook on the view logbook screen.

• Pre-Conditions: User must be logged in. User must have aircraft records. User must have logbook entries.

• Post-Conditions: Logbook entries are printed.

• Actors: User.

Use Case Diagram

Figure 11: Use Case Diagram

Class Diagram

Figure 12: Class Diagram

7 .3 .6 .3 In t e rn a l I nt e rf a ce De s ign

None.

7 .3 .6 .4 Da t a ba s e De s ign

Entity Relationship Diagram

Figure 13: Data Model Diagram

Data Dictionary

Figure 14: Data Dictionary - Part 1

Figure 15: Data Dictionary - Part 2

7 .3 .6 .5 Da t a Re qu ire m e n t T ra ce a bi lit y

Figure 16: Data Requirement Map – Part 1

Figure 17: Data Requirement Map – Part 2

7 .3 .6 .6 Us e r I nt e rf a ce De s ign

Below are the screenshots for the system. They contain the standard look and feel.

Figure 18: View Logbook Screen Layout

Figure 19: Aircraft Screen Layout

Figure 20: Add/Edit Entry, Main Tab Screen Layout

Figure 21: Add/Edit Entry, Type of Hours Tab Screen Layout

Figure 22 : User Profile Screen Layout

7.3.7 Ris ks a n d Is s u e s

• There is not, as yet, a backup or disaster recovery plan.

7.3.8 Ve rs io n H ist o ry

Version Date Changes Made 1.0 10/10/2005 Initial Release

7.4 T est P la n a n d T e s t C a s es

7.4.1 S yst e m Ove rvie w

Refer to Statement of Work (Section 7.1).

7.4.2 Test Plan

This section will describe an overview of how the testing will be conducted.

A test database schema will be created that will exactly mirror the production database. Since this is the first release to production for the system, the software will be loaded onto the production server in accordance with the Implementation Plan (Section 7.5). This will allow us to test the Implementation Plan as well, troubleshooting any issues that are encountered. When implementation is done, the system will be configured to connect to the testing schema.

After Implementation Plan has been successfully completed, the test cases can be executed. If an error is found, an error report is created containing the build number, function or GUI that failed, a short description of the error condition, steps to recreate the problem, and the severity of the error.

When the testing cycle is completed (within a reasonable timeframe), a report and review of the test plan with results will be performed. The team will proceed to the Implementation Step if the stakeholders sign off on the test results.

7.4.3 T est C a s es

7 .4 .3 .1 Lo gin T e s t C a s e

Functional Number: 7.3.4.1.1 Requirement Number(s): 7.2.3.2.1; 7.2.3.2.2 Steps • Tester enters a correct login/passwd combo. Tester clicks on "login" link. Expected Results Website should display properly. Upon login, the tester should be granted access and the view logbook page displayed. User's login id would be shown in upper right corner of GUI. Actual Results

Pass/Fail:

Remarks

7 .4 .3 .2 A dd/ e dit U s e r P ro f ile

Functional Number: 7.3.4.1.2 Requirement Number(s): 7.2.3.2.9 Steps • Tester Clicks on "new user" link. • Tester enters user profile data in system form. Clicks save. • Tester enters newly created login/passwd. Clicks on "login" link. Expected Results Website should display properly. upon clicking "new account" link, system should display User profile GUI. The user profile record should be saved. New login/passwd should allow access and display view logbook GUI. Actual Results

Pass/Fail:

Remarks

7 .4 .3 .3 Dis pla y Fli gh t L o g

Functional Number: 7.3.4.1.3 Requirement Number(s): 7.2.3.2.15 Steps • Tester enters a correct login/passwd combo. Tester clicks on "login" link. • Tester clicks on view flight log on left side nav. Menu. Expected Results In both steps above, the view flight log screen will be displayed. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .4 Dis pla y Re po rt s

Functional Number: 7.3.4.1.4 Requirement Number(s): 7.2.3.2.6; 7.2.3.2.7; 7.2.3.2.8 Steps • Tester clicks on each report link on the left hand nav. Menu. Expected Results The appropriate report should be displayed on the screen when that report’s respective link is clicked on.

Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .5 P rin t Fligh t Lo g Functional Number: 7.3.4.1.5 Requirement Number(s): 7.2.3.2.14 Steps • From the View Logbook GUI, the test clicks Print Logbook. Expected Results The logbook should print at the printer configured on the computer system being used for the test. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .6 A dd/ e dit / de le t e L o gbo o k E n t ry Functional Number: 7.3.4.1.6 Requirement Number(s): 7.2.3.2.3; 7.2.3.2.4 Steps • Tester clicks on Add/Edit Entry on left side nav. Menu. • Tester creates a new record and saves. • Tester navigates to view logbook to see record displayed. • Tester navigates back to add/edit entry and queries record. • Tester modifies fields on the form and saves record.

• Tester navigates back to View Logbook to verify changes. • Tester clicks delete link to the left of the record. Expected Results The record should be created and then displayed in the View Logbook GUI. The record, after being modified, should display with the new data in the View Logbook GUI. When deleted the record should be removed from the database and not visible in the GUI anymore. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .7 A dd/ E dit A ircra f t Functional Number: 7.3.4.1.7 Requirement Number(s): 7.2.3.2.5 Steps • Tester clicks on Aircraft link on left side nav. Menu. • Tester creates new aircraft record and saves. • Tester verifies aircraft is available in the Add/Edit Entry GUI. • Tester returns to Aircraft GUI, queries new record, modifies record and saves. • Tester verifies the changes by selecting an appropriate report from the Reports menu. Expected Results The aircraft record should save successfully and be usable in the system in both the create and update modes. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .8 A dd/ e dit P ilo t C e rt if ica te s Functional Number: 7.3.4.1.8 Requirement Number(s): 7.2.3.2.10 Steps • Tester navigates to Pilot Certificate GUI. Creates new certificate record.

• Tester then navigates away from Pilot Certificate GUI and then navigates back and queries the Certificate. • Tester modifies new Certificate Record and saves. Clears GUI and then queries certificate record again. Expected Results The Certificate record should be created and display in Pilot Certificate GUI for both create and update scenarios. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .9 A dd/ E dit P ilo t Ra t in gs Functional Number: 7.3.4.1.9 Requirement Number(s): 7.2.3.2.11 Steps • Tester navigates to Pilot Rating GUI. Creates new rating record. • Tester then navigates away from Pilot Rating GUI and then navigates back and queries the Rating. • Tester modifies new rating record and saves. Clears GUI and then queries rating record again. Expected Results The rating record should be created and display in Pilot Rating GUI for both create and update scenarios. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .1 0 A dd/ E dit Fligh t P ro f icie n c y Functional Number: 7.3.4.1.10 Requirement Number(s): 7.2.3.2.12 Steps • Tester navigates to Flight Proficiency GUI. Creates new proficiency record. • Tester then navigates away from Flight Proficiency GUI and then navigates back and queries the proficiency.

• Tester modifies new proficiency record and saves. Clears GUI and then queries proficiency record again. Expected Results The proficiency record should be created and display in Flight Proficiency GUI for both create and update scenarios. Actual Results

Pass/Fail (circle one)

Remarks

7 .4 .3 .1 1 A dd/ E dit M e dica l C e rt if ica t e Functional Number: 7.3.4.1.11 Requirement Number(s): 7.2.3.2.13 Steps • Tester navigates to Medical Certificate GUI. Creates new medical certificate record. • Tester then navigates away from Medical Certificate GUI and then navigates back and queries the medical certificate. • Tester modifies new medical certificate record and saves. Clears GUI and then queries medical certificate record again. Expected Results The medical certificate record should be created and display in Medical Certificate GUI for both create and update scenarios. Actual Results

Pass/Fail (circle one)

Remarks

7.4.4 Ve rs io n H ist o ry

Version Date Changes Made 1.0 10/10/2005 Initial Release

7.5 Implementation Plan

7.5.1 S yst e m Ove rvie w

Refer to Statement of Work (Section 7.1).

7.5.2 Im ple m e n t at io n S te ps

• Create tar file of the files to be loaded to production. • Perform a checksum on the tar file. • FTP tar file to the production server. • Perform a checksum on the tar file from the production server. • Extract the tar file. • Navigate with a web browser to the website for the application and perform testing.

7.5.3 Im ple m e n t at io n Ba cko u t S t e ps

• Remove all files from the production directories. • Delete tar file from server.

7.5.4 Ve rs io n H ist o ry

Version Date Changes Made 1.0 10/10/2005 Initial Release

CH A P T E R VII I C ON CL U SI ON

The idea for this report came about almost one year prior to its submission.

In its early stages, the concept evolved quite a bit. As time passed, the focus changed from a technical to more a conceptual approach. One of the reasons for this was because of time constraints; however, another reason was that in doing the research for the project, in addition to the published sources, I took the opportunity to speak to many of my past and present colleagues – and a couple of mentors – about not just the technical side of things, but about their philosophy of software development. As we shared our past experiences, I began to see a common thread among those projects that were successful and those that failed.

That common thread was the structure and support of management. Without fail, those managers who operated with a mindset that they were there to support their team had a much higher rate of success. Conversely, managers who operated with a mindset that the team was there to support them had a much lower rate of success. When that realization was made, it became apparent that successful software is highly dependent upon the environment in which it is developed. With this new information, I changed the primary objective of the project from a more technical to a more philosophical focus. I developed ideas about how to structure a company by emulating those companies that, in my research, showed that they could be successful with a different approach than I was used to. It is my hope that these ideas can be of help to and implemented by individual engineers and teams at a lower level, even if their company does not necessarily promote the ideas shared in this report at a higher level.

REFERENCES

1. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 23. 2. Costco Corporation. Code of Ethics. http://media.corporate- ir.net/media_files/NSD/cost/reports/our_mission.pdf 3-5. Greenhouse, Steven. "How Costco became the Anti-Wal-Mart." New York Times 17 July 2005. 6. Ben & Jerry's Ice Cream. 19 Sept. 2005 . 7. Dictionary.com. 19 Sept. 2005 . 8. Webb, Bradley. Former PM Nortel Networks, Global Repair Services, IS. Telephone interview. 10 Aug. 2005. Subject Matter Expert discussed experiences at Nortel Networks regarding core values. 9. Raytheon Diversity. 18 Sept. 2005 . 10. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 43. 11. Covey, Stephen R. The Seven Habits of Highly Effective People. 1st ed. Free P, 1990. 12. Charles, Watson, MSgt USAF(Retired). Telephone interview. 3 Aug. 2005. Subject Matter Expert regarding military "corporate" culture from experiences with the United States Air Force. 13. "Santa Clara County v. Southern Pacific Railroad Company." Touro Law Center. 9 Oct. 2005 . Supreme Court of the United States decision. 14. Cohen, Ben, and Jerry Greenfield. Ben Jerry's Double Dip : Lead With Your Values and Make Money, Too. Simon & Schuster, 1997. 15-16. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 9. 17. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 10. 18. "Software Engineering." Wikipedia: The Free Encyclopedia. 15 Sept. 2005 . 19. "Standards Make Good Business Sense." IEEE. 21 Sept. 2005 . 20-25.Hogan, Michael. "GUI Guidelines and Adoption Procedures for Custom Applications." Master’s Report, Texas Tech Univ., 2005.

26. United States Government. Federal Aviation Administration. FAA Factbook, August 2005. 2005. 27. United States Government. Federal Aviation Administration. FAA Aerospace Forecasts: Fiscal Years 2005-2016. 2005. 28. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 63. 29. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 106. 30. Yeh, Raymond T. The Art of Business: In the Footsteps of Giants. Olathe, CO: Zero Time, 2004. 165. 31-32. Charles, Watson, MSgt USAF(Retired). Telephone interview. 3 Aug. 2005. Subject Matter Expert regarding military "corporate" culture from experiences with the United States Air Force. 33. Clark, Wesley. "It All Comes Back to Leadership." TPM Cafe. 01 Sept. 2005. 01 Sept. 2005 . On the subject of leadership. 34. Charles, Watson, MSgt USAF(Retired). Telephone interview. 3 Aug. 2005. Subject Matter Expert regarding military "corporate" culture from experiences with the United States Air Force. 35. Maccoby, Michael. "Understanding the Difference Between Management and Leadership." The Maccoby Group. 20 Jan. 2000. 6 Oct. 2005 . 36. Robbins, Steven. "The Difference Between Managing and Leading." Entrepreneur.com. 18 Nov. 2002. 6 Oct. 2005 . 37. Charles, Watson, MSgt USAF(Retired). Telephone interview. 3 Aug. 2005. Subject Matter Expert regarding military "corporate" culture from experiences with the United States Air Force. 38. United States Air Force. Hurlburt Field Airman Leadership School Student Informational Brochure. 2003. 39. Charles, Watson, MSgt USAF(Retired). Telephone interview. 3 Aug. 2005. Subject Matter Expert regarding military "corporate" culture from experiences with the United States Air Force. 40. "Situational Leadership Theory." Wikipedia: The Free Encyclopedia. 7 Oct. 2005 .

A P P E N DI X A : S OFT W A RE DOC U M E N T AT I ON T E M PL A T E S

STATEMENT OF WORK

1 Project Overview This section will be a general description of the project.

1.1 Business Needs This sub-section describes the business need for the system.

1.2 Customer Profile This sub-section describes the customer profile.

1.3 Customer Goals This sub-section describes the customer’s goals regarding the system.

2 Preliminary Requirements This section discusses the overall requirements of the project.

2.1 Scope of Work to be Done This sub-section describes the scope of the work, as opposed to the scope of the system.

2.2 Critical Constraints This sub-section describes the critical constraints the system will be operating under.

2.3 Functional Requirements This sub-section describes the high level functional requirements of the system.

2.4 Project Deliverables This sub-section describes the deliverables expected from the project.

2.5 Standards This sub-section describes the standards that will be applied.

2.6 Target Environment This sub-section describes the target environment.

2.7 Summary of Customer Priorities and Expectations This sub-section contains the priorities of the customer and their expectations when the system is complete.

2.8 Security This sub-section briefly describes the security of the system.

A-1

3 Project Schedule This section describes the approximate timeframe for the project and how long the resources are to be utilized.

4 Development Environment This section describes the development environment.

5 Version History This section contains a history of how the document has changed. Every time a change is made, an entry is added to this section.

A-2

Requirements Specification

1 System Overview This section is a brief statement on the purpose of the system being built.

2 Reference Documents This section contains references to other important documents related to the system.

2.1 Project Documents This sub-section contains a link to any other documents within the project.

2.2 Other Documents This sub-section contains a link to any other documents within the project.

3 Requirements This section contains all requirements for the system.

3.1 Hardware Requirements This sub-section contains the requirements about the hardware of the system.

3.2 Software Requirements This sub-section contains the requirements about the software of the system.

3.3 Interface Requirements This sub-section contains the requirements about the interfaces of the system.

4 Notes This section contains information of a general or explanatory nature that may be helpful.

4.1 Definitions Used in this Document Insert here an alphabetic list of definitions and their source.

4.2 Abbreviations Used in this Document Insert here an alphabetic list of the abbreviations and acronyms.

A-3

5 Version History This section contains a history of how the document has changed. Every time a change is made, an entry is added to this section.

A-4

DESIGN DOCUMENT

1 Scope This section will describe the general scope of the system.

2 Design Constraints This section describes the design constraints that govern the system.

3 Design Approach This section describes the design approach and why it was chosen.

4 Top Level Component Identification This section describes the overall purpose of the system and the major functions and interfaces.

4.1 Functions of Major Components This sub-section describes the functions assigned to major components of the system.

4.2 Data Flow This sub-section describes the interface among components depicting the data movement between processes or files.

4.3 Function Control This sub-section describes timing and dependencies for the processes and data flows.

4.4 Functional Mapping This sub-section shows traceability from functional requirements to components.

5 External Interfaces This section describes any interfaces that have to work with the system from outside the system.

6 Detailed Design This section contains system design.

A-5

6.1 Design Standards This sub-section describes any naming or customer standards that apply to all components of the system. A reference to any standards that the project MUST meet is here.

6.2 Component Detailed Design This sub-section describes detailed info of each component.

6.3 Internal Interface Design This sub-section describes the data flows and interface dependencies between the lower-level components.

6.4 Database Design This sub-section describes the tables, columns, keys, mandatory columns, and relationships between the tables of the system’s database.

6.5 Data Requirement Traceability This sub-section maps the data requirements to the data elements.

6.6 User Interface Design This sub-section describes the layout of the screens/panels/windows/etc.

7 Risks and Issues This section contains paragraphs to describe design risks and assumptions and ways that they could impact the schedule for coding, testing, installation.

8 Version History This section contains a history of how the document has changed. Every time a change is made, an entry is added to this section.

A-6

TEST PLAN AND TEST CASES DOCUMENT

1 System Overview This describes the purpose of the system and the software to which this document applies.

2 Test Plan This section describes the overall approach to testing the system.

3 Test Cases This section lays out the test cases with instructions on how to execute the test cases. It includes a reference to which requirement is being tested and spaces for test results. This document also serves as a test report after testing is completed.

4 Version History This section contains a history of how the document has changed. Every time a change is made, an entry is added to this section.

A-7

IMPLEMENTATION PLAN

1 System Overview This describes the purpose of the system and the software to which this document applies.

2 Implementation Plan This section describes the step-by-step plan to implement the system to production.

3 Implementation Back Out Plan This section describes the step-by-step plan to back out if the implementation if there is a problem along the way. The goal of this section is to return the production system to its original state, before the implementation was started.

4 Version History This section contains a history of how the document has changed. Every time a change is made, an entry is added to this section.

A-8

A P P E N DI X B : S OFT W A RE C ODI N G S T A N DA RD S

1 Editor Settings Tabs vs. Spaces: Spaces should be used instead of tabs for indenting code. Feel free to decide how many spaces constitute “good indention” but be consistent. Most IDEs and code editors allow the number of spaces for indention to be configured.

Linefeeds: Ensure that your editor is saving files in the UNIX format. This means lines are terminated with a newline, not with a CR/LF combo as they are on Win32, or whatever the Mac uses. Any decent Win32 editor should be able to do this, but it might not always be the default.

2 Naming Conventions Where possible the industry accepted conventions of the language used should be followed. Where no convention exists, please use the examples below as your guide.

Variable Names: Variable names should be in all lowercase, with words separated by an underscore, example:

Incorrect: currentuser currentUser Correct: current_user

Names should be descriptive, but concise. Long sentences are not necessary, but typing an extra couple of characters is always better than wondering what exactly a certain variable is for.

Loop Indices: The only situation where a one-character variable name is allowed is when it's the index for some looping construct. In this case, the index of the outer loop should always be i. If there's a loop inside that loop, its index should be j, followed by k, and so on. If the loop is being indexed by some already-existing variable with a meaningful name, this guideline does not apply, example:

for (i = 0; i < outer_size; i++) { for (j = 0; j < inner_size; j++) { foo(i, j); } }

Function Names: Functions and methods should be named descriptively and using the industry accepted naming conventions for the language. Where no such convention exists, use all lower-case names with words separated by a single

B-1

underscore character. Function and method names should preferably have a verb in them somewhere. Examples of good function and method names are:

getLoginStatus(); setLoginStatus();

Function and Method Arguments: Arguments are subject to the same guidelines as variable names.

Summary: The basic philosophy is to not hurt code clarity for the sake of laziness. This has to be balanced by a little bit of common sense, so that variable names do not end up being too long.

3 Code Layout Standard header for new files: Here a template of the header that must be included at the start of all files (values in between $ will be replaced by the configuration management code repository tool automatically):

/***************************************************** * Filename: * * Description: * * ------* Last Checked In By : $Author$ * Last Checked In On : $Date$ * Public Revision No : x.y.z * Internal Revision No : $Revision$ * * Copyright statement * *****************************************************/

Always include the braces: This is another case of being too lazy to type 2 extra characters causing problems with code clarity. Even if the body of some construct is only one line long, do not drop the braces. Examples:

Incorrect: if (condition) do_stuff();

if (condition) do_stuff();

while (condition) do_stuff();

for ($i = 0; $i < size; $i++) do_stuff($i)

Correct: if (condition) {

B-2

do_stuff(); }

while (condition) { do_stuff(); }

for ($i = 0; $i < size; $i++) { do_stuff(); }

Where to put the braces: Braces always go on their own line. The closing brace should also always be at the same column as the corresponding opening brace, examples:

if (condition) { while (condition2) { ... } } else { ... }

for (i = 0; i < size; i++) { ... }

while (condition) { ... }

doSomething() { ... }

Use spaces between tokens: Always leave one space between the tokens. Basically, put spaces between variable names and operators. Do not put spaces just after an opening bracket or before a closing bracket. Do not put spaces just before a comma or a semicolon. Examples:

Each pair shows the wrong way followed by the right way.

i=0; i = 0;

B-3

if(i<7) ... if (i < 7) ...

if ( (i < 7)&&(j > 8) ) ... if ((i < 7) && (j > 8)) ...

doSomething( i, "foo", b ); doSomething(i, "foo", b);

for (i=0; i

SQL Code Layout: Organize SQL key words on their own line and use capitalization for SQL keywords. Please see the following examples:

SELECT column1, column2, column3 FROM table a, table b WHERE (a.this_pk = b.this_fk) AND (a.that = myvalue);

UPDATE table a SET column1 = newValue, column2, = newValue2 WHERE a.pk_column = value;

Comments: Each function or method should be preceded by comments that state its purpose. Every parameter, the expected input, and the output are required as a minimal comment. The function's behavior in error conditions (and what those error conditions are) should also be present.

All comments should be in this format:

/* Put comment openers and closers on a line by themselves. All appropriate comments will fall in here */

In the case of languages for which a documentation utility is provided, such as javadoc for Java, use the appropriate comment markers. Example:

/** This is a javadoc comment. */

In addition, comment any tricky, obscure, or otherwise not-immediately-obvious lines of code. This can be done with a single line comment. Example:

// This is a single line comment.

Magic Numbers: Use named constants for any literal value other than obvious special cases. For example, use the constants TRUE and FALSE in place of the literals 1 and 0 in languages where applicable.

B-4

Shortcut operators: Avoid using increment (i++) or decrement (i--) within an expression. Increment and decrement operators should only be used as part of a looping structure or on a separate line. Examples:

Incorrect: Array[++i] = j; array[i++] = k;

Correct: i++; array[i] = j;

array[i] = k; i++;

Ternary Operator: The ternary operator ( condition ? true_result : false_result ) should never be used. It is confusing and unreadable. : GLOSSARY

B-5

APPENDIX C: GLOSSARY

ALS: Airman Leadership School – The first level of Professional Military education in the United States Air Force to prepare enlisted personnel for their first supervisory experiences. API: Application Programming Interface – a set of definitions of the ways one piece of computer software communicates with another. Beta Testing: Limited public testing to a subset of the expected user population to ensure the product has few faults or bugs prior to final production release. COTS: Commercial Off The Shelf – Software that is purchased ready made and generally works “out of the box”. CRB: Change Review Board – A group of representatives for each area of a software development team that provide input for and priority to requested changes in software. EPME: Enlisted Professional Military Education – The branch of training in the respective military services responsible for improving the leadership skills of their enlisted corps. FAA: Federal Aviation Administration – U.S. government agency which regulates and oversees all aspects of civil aviation in the U.S. FAT: Factory Acceptance Test – A test conducted at the factory (before product delivery) to ensure compliance with the system’s requirements. FBO: Fixed Based Operator – a service center at an airport that may be a private enterprise or may be a department of the municipality that the airport serves. IDE: Interactive Development Environment – A software package that allows developers to create software by partially automating some of the mundane and repetitive coding tasks within a GUI. RAD: Rapid Application Development – A methodology for engineering software that is characterized by iterative development, the construction of prototypes, and the use of Computer-aided software engineering (CASE) tools. Traditionally the rapid application development approach involves compromises in usability, features, and/or execution speed. Requirements Creep: The tendency for new requirements to be added to a software development process during the design and development phases of a project. SAT: Site Acceptance Test – A test conducted at the production (upon delivery) to ensure compliance with the system’s requirements. Senior Airman: The highest junior enlisted rank in the United States Air Force. It is equivalent of an Army Specialist and Corporal, Navy Petty Officer Third Class, and Marine Corporal. It has military a pay grade of E-4.

C-1

Private Pilot (Certificate): A certificate that permits the holder to operate an aircraft, usually only under visual flight rules. In most countries, a private pilot possessing an instrument rating may also conduct flights under instrument flight rules. Sport Pilot Certificate: A pilot certificate that allows the pilot to operate a light- sport aircraft (a small, low-powered aircraft), under a limited set of flight conditions. It is the only U.S. pilot certificate for powered aircraft that does not require a medical examination; a driver's license can be used as proof of medical competence. Student Pilot (Certificate): Certificate that is issued to a pilot in training, and is a pre-requisite for the student to fly alone in the aircraft. It is usually initially issued by an aviation medical examiner in combination with the student’s first medical certificate. VPV: Vision, Purpose, Values – A set of statements in a corporation that define its mission, how it hopes to achieve that mission and the principles by which they will abide to achieve that mission.

C-2