180 likes | 359 Views
Software Engineering as a Career. Craig Henderson , CRTS Graduate 1995 Software Development Manager Aviation Information Solutions Rockwell Collins (UK) Ltd. AIS Software Development (1). A mature and capable development team
E N D
Software Engineering as a Career Craig Henderson, CRTS Graduate 1995 Software Development Manager Aviation Information Solutions Rockwell Collins (UK) Ltd
AIS Software Development (1) • A mature and capable development team • Current team of 9 developers have in excess of 110 man years combined commercial software development experience • Over 45 man years of HERMES™ product development experience exists within RCUK • Average developer years of service is 7.3 • Development is controlled by work packages • All development work is undertaken within the scope of a formal Work Package
AIS Software Development (2) • Traditional Waterfall Development Lifecycle • Using industry standard methodologies ensures that the process is comprehensible and transparent • Peer Reviews • Rigorous Software Testing • 3 varieties of testing; implementation testing, continuous automated testing, full system testing
AIS Software Development (3) • ISO 9001 Quality Assured • Well defined processes for Software Development • Business • Technical • Each release of software is verified by the QA team before delivery to the customer solution team
Work Packages (1) • Scope • A Work Package covers the technical requirements, design, implementation and testing of a self contained unit of software development • The business requirements and estimates will have been defined prior to raising a Work Package • Work Packages are signed off by management before work commences to enable effective resource allocation • Purpose • Software change control • Define the scope of work to be done • Define baseline timescale and record actual progress • Define budget and identify resources
Work Packages (2) • Benefits • Traceability and visibility of software changes • Eases project, resource and release management • Provide predictable, controlled and scalable development capability
Peer Review (1) • Scope • Peer Reviews are conducted by Development Engineers • Requirement reviews • Design reviews • Implementation reviews • Purpose • Quality control of the development process and the software • Validation of design and implementation against requirements • Information sharing
Peer Review (2) • Benefits • Improved software quality • Early indication of inaccurate or missing details • Knowledge is shared among engineers • Engineering team scalability
Language Choice • Choose a language to specialise in, and learn as much of it as possible • Be flexible in your work to write code in other languages besides your chosen specialist one • Don’t slate other languages because they’re not your chosen one • Understand the alternatives and be ready to make decisions on which to use • Top four languages of choice • C • C++ • JAVA • C# Use the right tool for the job
Language Expertise • Read the language specification, keep a copy to hand • Understand implementation details. For example: • Know what a vtable is for, and the impact it has on the runtime of your system • Understand what, when and why the compiler generates code for you, e.g. class methods • Be able to recognise the fringe language features, and in time, learn them • explicit, mutable keywords
Language Expertise –A C++ example: Use of the const keyword (1) • What is the const keyword for? • It is used to mark an entity as constant, i.e. read-only; not modifiable • What entities can it be used with? • Data objects • const int max_value = 36; • Class member functions • class foo • { public: • void bar(void) const; • private: • int value_; • }; max_value cannot be changed (at least directly) bar() cannot modify value_
Language Expertise –A C++ example: Use of the const keyword (2) • What entities can it be used with (continued)? • Pointers to object • const char *message = “Hello World!”; • char const *message = “Hello World!”; • const char * const message = “Hello World!”; • Tip: always put the const to the right of the entity: • char const *message = “Hello World!”; • char * const message = “Hello World!”; • char const * const message = “Hello World!”; • Each of the three statements above is allowed by the language, but which is not semantically correct?
Platform Expertise • Know your platform(s) • Platform UI design practice • Understand platform specific performance implications of design/implementation choices • Mutex vs Critical Section
Good Practices • Learn good practices, employ them in your work and advocate them to others • Use const types as return values • Method overloads to reduce redundancy and increase performance • References • All books by Scott Meyers • All books by Andrei Alexandrescu • All books by Herb Sutter • C/C++ Users Journal, CMP Media • Ways to Improve • Practice • Read the language specification • Write; technical documentation, articles
Changing Jobs • Changing jobs is good for you & your career • Changing jobs doesn’t have to mean changing employers • Don’t get stuck in a comfortable existence • But don’t change too often • Have a good Curriculum Vitae • Don’t get nervous at interview – it’s only a job
Interview Test #define MIN_AGE = 0 #define MAX_AGE = 150 #define MAX_NAME_STR_LEN = 255 #define MAX_ADDR_STR_LEN = 1024 class CPerson private CObject { public char GetName() { return szName } int GetAge() { return iAge } char GetAddress() { return szAddress } protected int SetName(char* szName) { m_szName = szName } int SetAge(int* iAge) { if (iage < MIN_AGE) | (iage > MAX_AGE) throw "Invalid Age" iage; else m_iAge = iAge; int SetAddress(char* szAddress) { m_szAddress = szAddress } private CPerson() {} ~CPerson() {} static char* m_szName[MAX_NAME_STR_LEN] = ""; const int m_iAge = -1; static char* m_szAddress[MAX_ADDR_STR_LEN] = ""; }
Interview Test – Model Answer No comments were in the original code to give context or document intent, so assumptions have been made. class CPerson :public CObject { public: static int const MIN_AGE = 0; static int const MAX_AGE = 150; CPerson() : age_(0) {} ~CPerson() {} std::string const &GetName() const { return name_; } int const GetAge() const { return age_; } std::string const &GetAddress() const { return address_; } void SetName(char const *name) { name_ = name; } void SetName(std::string const &name) { name_ = name; } bool const SetAge(int age) { if (age < MIN_AGE || age > MAX_AGE) return false; else age_ = age; return true; } bool const SetAddress(std::string const &address) { return SetAddress(address.c_str()); } bool const SetAddress(char const *address) { if (address) { address_ = address; return true; } return false; } private: std::string name_; int age_; std::string address_; }; Could add additional constructor for initialisation. My preference is not to do this, keeping object construction and initialisation separate. All but the simplest accessor functions should be implemented in a separate implementation file (e.g. cpp) Code comments should also be added to describe the purpose of the class, document specific design decisions, identify author & change history.
Contact Craig Henderson Software Development Manager Aviation Information Solutions Rockwell Collins (UK) Ltd Reading Berkshire RG6 1LA 0118 935 9211 [direct] chenders@rockwellcollins.com