Monday, August 28, 2006

Software Engineering Code of Ethics

Software engineers shall commit themselves to making the analysis, specification, design, development, testing, and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety, and welfare of the public, software engineers shall adhere to the following Principles:
  • Public: Software engineers shall act consistently with the public interest.
  • Client and Employer: Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
  • Product: Software engineers shall ensure their products and related modifications meet the highest professional standards possible.
  • Judgment: Software engineers shall maintain integrity and independence in their professional judgment.
  • Management: Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
  • Profession: Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
  • Colleagues: Software engineers shall be fair to and supportive of their colleagues.
  • Self: Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

The Code instructs practitioners about the standards that society expects them to meet, and what their peers strive for and expect of each other.

Ref: Communications of the ACM, Volume 42, Number 10 (1999), Pages 102-108

Wednesday, August 23, 2006

Principles behind the Agile Manifesto

Principles behind the Agile Manifesto
We follow these principles:

  • Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly


Saturday, May 27, 2006

More Interview Tips and Some Sample Questions

Some Common and Sample Interview Questions:

Tell me about a time when you had to work really hard to get something done? How did you set priorities, and what was the result?

Key Components in Your Response:

Briefly describe the situation.
"There was an instance recently when I had two tests and a research proposal due one week and was asked to take on an extra shift at work. I am also the Vice President of the Accounting Club, where I typically facilitate monthly meetings. One was also scheduled for this same week. It was clear that my time constraints might impact one or more of these responsibilities and that I needed to develop a strategy to get things done."

Identify the steps that you had taken to respond to the situation.
"Since some of these responsibilities were expected, I had prepared for this week by conducting my literature review for the research proposal well in advance and had completed everything except the summary prior to this busy week. When asked to work an extra shift for another employee, I inquired further and learned that my coworker only needed a portion of this shift off. I agreed to work for three hours of the six-hour shift so that she could meet her goals and I could attend to mine. I was then able to budget my time effectively to study for my tests, while delegating some responsibility to other club members in facilitating our monthly Accounting Club meeting."

Identify the outcome (positive or negative). If negative, it is very important to state what it is you learned from the situation and what you would do differently next time.
"I submitted my proposal on time, and received an A on one test and a B on the other. My coworker expressed appreciation for my willingness to compromise by working a partial shift. Our Accounting Club meeting was productive, and it was great to see others take some ownership in the meeting by being responsible for various segments of the agenda.

Interview Attire
• The key here is to dress conservatively. Men are typically encouraged to wear a suit and a tie, while women are encouraged to wear a skirt or dress pants with a dress shirt and a coordinating jacket/blazer/sweater. It is wise to consult someone in the industry or a member of the Career Center for specific information.
• Jewelry would also be worn conservatively (small earrings/necklace etc.), and belts should match the shoes that are worn for the interview. It is important for shoes to be properly maintained.
• All apparel is clean and pressed. Attending to these details tells the employer whether or not you are serious about the job.
• Refrain from wearing fragrances, as many people experience adverse reactions to them. (chemical sensitivities)

Some Predictors of Success• Ambition and motivation
• Problem-solving skills
• Related work experience
• Creativity and intelligence
• Self-confidence
• Teamwork capabilities and work habits
• Strong communication skills
• Strong interpersonal skills
• Adaptability
• Leadership ability
15 Knockout Factors
(reasons why candidates receive rejection replies)
1. Lack of proper career planning; inability to define career goals and objectives
2. Lack of knowledge of field of specialization; not well-qualified
3. Inability to express self clearly
4. Insufficient evidence of achievement or capacity to excite action in others
5. Not prepared for interview; no research on company
6. No real interest in the organization or the industry; merely shopping around
7. Narrow location interest; unwilling to relocate later
8. Little interest and enthusiasm; indifferent
9. Overbearing, overaggressive and/or conceited
10. Interested only in best dollar offer
11. Asks no or poor questions about the job
12. Unwilling to start at the bottom; expects too much too soon
13. Makes excuses; evasive; hedges on unfavorable factors in record
14. No confidence and poise; fails to look interviewer in the eye
15. Poor personal appearance and grooming

Job Interview Tips

First impression is the key of an interview success. You don't get a second chance to make the first impression impressive.

How Would You Prepare Yourself?

1. Learn about the company, the position and the people. Learn in advance as much as you can about a potential employer's business from their website.

2. Think of how best to communicate. Think about the best ways to describe your experiences and the projects you will present to interest, relate to and influence the people you are going to meet.

3. Prepare your portfolio/presentation materials. Think carefully about showing design work done much earlier in your career. To many potential employers, especially those who are not designers, older work simply looks dated, and this may work against you.

4. Rehearse. Ask your friends, colleagues or others whose judgment you trust to listen to your presentation and to tell you how you can improve. Ask them what they would want to know about people who are interviewing for positions with their companies

5. Get directions and travel specifics. Ask your recruiter for driving or any other travel directions if necessary, even if you will be taking a taxi airport.

Tips for the Interview

6. Be early. Plan to arrive at your appointment 15 to 30 minutes before the scheduled time. Planes and trains can be late and traffic can be unpredictable

7. Use waiting time wisely. If you must wait, use the time wisely by refreshing your memory. Read your resume and the materials the company provides about themselves in the waiting area. Be interested in your surroundings. Don't listen to a discman.

8. Mind your manners. Be nice to everyone, even receptionists and parking lot attendants. Make as many friends as you can throughout the interviewing process. Say "please" and "thank you" more frequently than usual.

9. Set up a "give and take" situation. Establish a balance between talking and listening. Do not try to dominate the conversation. Do not over-explain, pontificate or "lecture" to the people you are interviewing with. Be a sympathetic listener. Ask open-ended questions designed to draw out people so you can learn about them and how you may meet their needs.

10. Be genuine, interested and enthusiastic. Get comfortable with the people you are interviewing with as soon as you can. Be lively and expressive. Never speak in a monotone. Don't be afraid to laugh and smile. Make eye contact continually. If you are interested in the company, ask questions, especially about the position and performance objectives. If you are asked about your salary requirements, give a range, and be sure the information is consistent with what you told the recruiter.

11. Confidential information. Never reveal confidential information about past employers or projects you have worked on.

12. Communicate simply. Always use simple language that is easy to understand. Speak slowly and clearly but in a natural manner to ensure that you are understood. Avoid jargon, trite expressions and cliches.

13. Follow up. Call your recruiter immediately after your meetings while everything is fresh in your mind and give him/her your feedback and impressions. Remember to send "thank you" notes to everyone you met.

Personal Presentation

14. On the morning of the interview:
  • Take a shower or bath. Use deodorant.
  • Wash your hair.
  • Brush your teeth, and use mouthwash, if necessary. Carry mints or breath spray in case you need it before your meeting(s).
  • Clean your nails.
  • Use after-shave or fragrance sparingly.
  • Play uplifting music that makes you feel good.
  • Exercise if you are nervous.

15. Dress appropriately.

• In most situations, clothing should be neat, natural and not attention grabbing. The focus should be on your mind and work, not your outfit.
• If you are not sure about proper interviewing attire, ask your recruiter or the assistant of the person you are going to meet about the dress code of the company. Unless told otherwise, athletic shoes may not be appropriate for an interview.
• Use jewelry sparingly. Don't wear anything that makes noise.

(Content sources: and

Tuesday, May 09, 2006

Software Engineer is the Best Job in the USA

According to the CNN money survey, software engineering is the number one rank in the top 50 job in the USA. Please read the following CNN money article below for the detail.

Software Engineer
Why it's great Software engineers are needed in virtually every part of the economy, making this one of the fastest-growing job titles in the U.S. Even so, it's not for everybody.

Designing, developing and testing computer programs requires some pretty advanced math skills and creative problem-solving ability. If you've got them, though, you can work and live where you want: Telecommuting is quickly becoming widespread.

The profession skews young -- the up-all-night-coding thing gets tired -- but consulting and management positions aren't hard to come by once you're experienced.

What's cool Cutting-edge projects, like designing a new video game or tweaking that military laser. Extra cash from freelance gigs. Plus, nothing says cool like great prospects.

What's not Jobs at the biggest companies tend to be less creative (think Neo, pre-Matrix). Outsourcing is a worry. Eyestrain and back, hand and wrist problems are common.

Top-paying job Release engineers, who are responsible for the final version of any software product, earn six figures.

Education Bachelor's degree, but moving up the ladder often requires a master's degree.

Thursday, February 09, 2006

The Future of Software Engineering Tools and Environments

Tools and environments to aid developers in producing software have existed, in one form or another, since the early days of computer programming. They are becoming increasingly crucial as the demand for software increases, time-to-market decreases, and diversity and complexity grow beyond anything imagined a few decades ago. In this paper, we briefly review some of the history of tools and environments in software engineering, and then discuss some key challenges that we believe the field faces over the next decade.

Future Chanllenges in Software Engineering

• The development of methodologies, formalisms, and tool and environment support for separation, extraction and integration of concerns.
• Linguistic and tool support for morphogenic software: software that is malleable for life, sufficiently adaptable to allow context mismatch to be overcome with acceptable effort, repeatedly, as new, unanticipated contexts arise.
• The development of new methodologies, formalisms, and processes to address nontraditional software lifecycles, and the tool and environment support to facilitate them.
• The development of new methodologies, formalisms, processes and tool and environment support to address the engineering of software in new, challenging domains, such as pervasive computing and e-commerce.
• The adoption or adaptation of XML, Enterprise Java Beans and sophisticated message brokering for integration of both tools and commercial applications.

Reference: Harold Ossher, William Harrison, and Peri Tarr; “Software engineering tools and environments: a roadmap, Proceedings of the Conference on The Future of Software Engineering, May 2000

Teaching Software Engineering in Human Aspect

This paper highlights the teaching of human aspects of software engineering, by presenting a course that deals with this topic.


Lesson 1 - The Nature of Software Engineering: The aim of this lesson is to increase learners’ awareness of the fact that most of the reasons for software development success and failure are people-centered reasons, not technology. This target is achieved by asking students to analyze development environments and situations that illuminate different humanrelated topics.

Lesson 2 - Software Engineering Methods: This lesson aims at increasing learners’ awareness of the human aspects of software development methods. This target is achieved by analyzing what goes on in the daily life of individual software engineers when they work according to a specific process.

Lesson 3 - Working in Software Teams: Our aim in this lesson is to let learners comprehend the influence of teamwork on the actual process of software development. Specifically, dilemmas that are relevant for software teamwork are discussed.

Lesson 4 - Software as a Product: This lesson highlights customers’ importance and role in software development environments. Accordingly, special emphasis is put on topics related to requirements (e.g., requirement gathering and understanding).

Lesson 5 - Code of Ethics of Software Engineering: In this lesson learners are introduced to the concepts of ethics in general and the Code of Ethics of Software Engineering in particular. This lesson aims at educating students to identify situations in which ethical considerations should be intertwined in software development processes and to conceive the Code of Ethics of Software Engineering as a tool that can be used both for the identification of ethical dilemmas as well as for their solving.

Lesson 6 - International Perspective on Software Engineering: This lesson highlights connections between global events and different cultures on SE processes. In addition, gender and minorities’ issues are discussed.

Lesson 7 - Different Perspectives on Software Engineering: This lesson aims at increasing learners’ awareness to the fact that SE can be viewed from different perspectives, each one emphasizing different aspects of the discipline. For this aim learners are introduced to different perspectives towards SE and are requested to examine what elements of each perspective fit their perception of SE.

Lesson 8 - The History of Software Engineering: The history of SE is used for illustrating that the nature of its short history is reflected in the nature of the field itself. Such connections are highlighted during the course in general and in this lesson in particular.

Lesson 9 - Program Comprehension, Code Inspections, and Refactoring: In this lesson learners are encouraged to observe connections between programming style and the daily life of software developers, for example, with respect to code inspections and refactoring processes.

Lesson 10 - Learning Processes in Software Engineering: This lesson highlights the cognitive aspect of software development processes. It is intended that learners will appreciate the importance of learning processes in SE in general and of a reflective mode of thinking in particular

Lesson 11 - Abstraction and Other Heuristics of Software Development: In this lesson learners become aware of heuristics that can guide the performance of different activities throughout the process of software development. Specifically, the concept of abstraction and its relevance and contribution to software development processes is examined.

Lesson 12 - Software as a Business: This lesson discussed in brief several business related issues to software development.

Lesson 13 - Case Studies of Software Engineering: In this lesson students are presented with case studies and examine them according to the cognitive and social theories presented so far in the course.

Lesson 14 - Students’ Summary Projects and Presentations: In this lesson students present case studies that they have developed, reflect on the construction process of their case studies and present questions for discussion related to their case studies.

Reference: Orit Hazzan and Jim Tomayko; Education & training track: Teaching human aspects of software engineering, Proceedings of the 27th international conference on Software engineering, May 2005

Thursday, November 17, 2005

Software Engineering Conferences

Software Engineering Conferences in 2005 and 2006

2005 Conferences

2006 Conferences

Thursday, November 03, 2005

Agile Modeling and the Rational Unified Process

Agile Modeling (AM) is a practices-based software process whose scope is to describe how to model and document in an effective and agile manner. The practices of AM should be used, ideally in whole, to enhance other, more complete software process such as eXtreme Programming (XP), the Microsoft Solutions Framework (MSF), the Rational Unified Process (RUP), the Agile Unified Process (AUP), and the Enterprise Unified Process (EUP) to name a few. These processes cover a wider scope than AM, in the first three cases the development process and in the fourth the full software process including both development and production. Although these processes all include modeling and documentation activities, in one form or the other, there is definitely room for improvement. In the case of XP and MSF the modeling processes should be better defined, and in the case of both the RUP and the EUP the modeling processes could definitely stand to be made more agile.
(For more information please Ref: Scott Ambler,

How Modeling Works in the Unified Process:

All efforts, including modeling, is organized into disciplines (formerly called workflows) in the UP and is performed in an iterative and incremental manner. The lifecycles of the AUP in Figure 1. The AUP is a subset of the RUP and the EUP a superset of the it. I like to say that the UP is serial in the large and iterative in the small. The six phases of the EUP clearly occur in a serial manner over time, at the beginning of an UP project your focus is on project initiation activities during the Inception phase, once your initial scope is understood your major focus becomes requirements analysis and architecture evolution during the Elaboration phase, then your focus shifts to building your system during the Construction phase, then you deliver your software during the Transition phase, you operate and support your software in the Production phase, and finally you remove it from production during the Retirement phase. However, on a day-to-day basis you are working in an iterative manner, perhaps doing some modeling, some implementation, some testing, and some management activities.

In the RUP there are three disciplines that encompass modeling activities for a single project – Business Modeling, Requirements, and Analysis & Design – and the EUP adds Enterprise Business Modeling and Enterprise Architecture. The AUP on the other hand, being a subset of the RUP, combines the three modeling disciplines into a single Model discipline.
(Ref: Scott Ambler, Agile Modeling and the Rational Unified Process, )