Software Engineering » Software Engineering

Why a Degree in Software Development Could Land You the Hottest Job in America

admin — Fri, 19 Mar 2010 06:59:29 +0000

Money Magazine rated Software Engineering as the number one, best job in America to have. I hope to shed some light on this career and provide some insight into why this particular job is so highly coveted. From job growth rates, pay, and flexibility, the job of software engineer gets high marks.

If you are thinking of becoming a Software Engineer, or Software Developer as it is also referred, you must be the type of person who doesn’t mind working alone without a lot of interaction with the public. While there is some interaction with your development team, you must be content working individually writing and testing code. In addition, you must be an innovative “out of the box” thinker who can quickly adapt to new programming languages and the rapidly evolving technology landscape. You must be able to apply knowledge of mathematics and computer science together in order to create software. Once the software is created, there is the testing phase. Once the testing phase is complete, it is time for implementation. While there is often a team of people working on a project, you must be able to see the programs you design through these phases. If you have the basic skills and predispositions to a scientific and analytical mind combined with a passion for computer science, becoming a software engineer could be a good fit for you.

Flexible Hours

Software Engineers are increasingly reaping the benefits of working from home or having a hybrid type schedule in which they work from a home office for designated days, then come back to the office for meetings with the rest of the team to collaborate. The flexibility of working from home and setting a loose, hybrid schedule lends itself to a more balanced lifestyle and a healthier more content workforce.

High Level of Compensation

In addition to the flexible hours, the skills of a Software Engineer typically come with a high level of compensation, relative to other jobs in the IT industry. The median wage for Software Engineers, according to the Bureau of Labor Statistics was $93,740 per year as of May 2008. The middle 50% earned between $73,200 and $113,960. The salaries vary depending on the type of employer you work for. Professional and commercial equipment wholesalers as well as software publishers tend to pay the highest salaries.

High Job Demand

Another reason Software Engineering jobs are considered among the hottest in America is because of the demand for these highly trained individuals. The Bureau of Labor Statistics describes the job prospects to be excellent. If you have at least a bachelor’s degree in a computer related field, you will usually have good prospects for finding a job. Some choose to achieve a master’s degree and others move into highly coveted positions simply based on their work experience and a portfolio of projects

It is no wonder, the job of Software Engineer has earned its reputation of being the hottest. If you are both mathematical and computer savvy, this is a job that could provide a flexible and lucrative career as well as a balanced lifestyle.

By: Jonathan Conrad

Software Testing and Quality Assurance

admin — Tue, 02 Mar 2010 22:44:54 +0000

Software testing can be defined as the process in which the tester aims at checking the software for errors and also, verifying that the functional requirements of a software are met. The system is examined under controlled conditions. The basic orientation is detection of faults within the system.

In this process, a program or an application is executed with the intentions of improving its quality. One strives to find the bugs within the software. As software industry has now grown in both size and complexity, so has its wide area of applications. We see soft wares in banking industry, in gaming industry, in management applications etc. Each has its own target customers and users. Before any software is launched, one must attempt to make an assessment as to its audience, customers, etc. The process of testing aims to aid in this regard.

Verification and Validation
Verification is a thwarting mechanism which helps in detection of all the possible weak points within a software before the process of testing actually begins.

Validation takes place after verification and this is where the concrete testing begins. One aims at finding the defects present in the functional requirements or the software’s specifications.

Software Quality
The quality of any software can be determined by the following yardsticks:

- It must be free of bugs
- It must be delivered on the due date
- It must be complete within the budget initially allotted
- It must meet all the requirements and expectations of the client

Software quality assurance
Software Quality Assurance or SQA, as it is popularly known, is a method by which one aims at monitoring the whole process of software engineering and take measures at appropriate durations for ensuring that the quality of the software is not compromised with. This is approached by use of audits of quality management system by which the system was initially built. A few examples of the quality standards are CMMI (Capability Maturity Model Integration) or ISO 9000.

SQA covers the whole process of development of any software and includes the design, coding, control of the code, reviews of the code, managing the configurations and the release of the final product. It is basically a method to control the processes of software development.

Advantages of SQA
- Improved customer satisfaction
- Reduced cost of development
- Reduced cost of maintenance
- Methodology of SQA
- Validation testing
- Data comparison
- Usability testing

By: Matthew Brone

Certified Software Project Manager

admin — Fri, 19 Feb 2010 21:38:05 +0000

Today more than ever there is a great need in the IT industry for competent and experienced software project managers. This is because today more than ever people are beginning to demand the highest quality software programs that meet their own particular requirements and budgetary constraints. Therefore if you are seriously interested in this particular area of the IT industry then you need to become a certified software project manager.

Although not all software companies require their employees to have this particular qualification it will certainly help when trying to get a job and also help you to get a much improved salary offer. But in order to obtain this certification you will actually need to return to school or college in order to complete the course. However if you find that you neither have the time or the funds to return full time to school/college to get this particular certification you can look at taking part in an online course instead.

On average it will take around 3 years in order for a person to complete all their training and to take the exams which will then provide them with the certification that they need. Generally you will find that most courses where a person wishes to become a certified software project manager it will be broken up into 6 individual courses which are as follows:-

1. What makes up the foundations of software project management.

2. The essentials with regards to software engineering.

3. The principles that relate to the testing of software.

4. Business context and the legal considerations in relation to software project management.

5. How to effectively management your own software teams/personnel.

6. Finally the importance of software quality assurance.

However once you have attained your certification upon completion of the course and passing the exams you will be able to define those tasks more clearly which are involved in relation to software project management. You will also find it much easier to complete a project that you are given effectively and efficiently. As the manager of the team it is your task to keep those within it motivated and you will be involved in all aspects of the project. From the planning stage through to the testing of the project.

Of all the roles that will be involved in the creation of a software product the role of the software project manager is the most important. Without a certified software project manager in charge of the project in hand then no will know what it is they are meant to be doing as well as when they should have it done by. Therefore if you are looking for a career in IT that offers you a challenge this may be the perfect job for you.

By: Paul Abbey

Software Engineering Online

admin — Sun, 29 Nov 2009 08:57:47 +0000

Programs presented by Online Software Engineering Schools guide students to better understand the various tasks and specialties that aid in software product development. Online Software Engineering coursework focuses on aspects of principles, techniques, tools, specifications, and guidelines of software development, as well as design and implementation of software.

Online Bachelor’s degrees in Software Engineering require courses in math and science, computer networks, principles of Software Engineering, and programming. Software Engineering students will use Java and C++ software, as well as others, as a degree requirement. Courses in Software Engineering present tools and techniques that enhance theoretical knowledge and implementation of software and software development.

A Bachelor’s degree in Software Engineering can be achieved completely online. The degree will provide the skills that allow graduates to excel in applications of computer systems, applications, and networks. Specializations in Software Engineering programs allow the student to focus on applications and systems, creation of new computer software and systems, or modification existing applications and systems. Some Software Engineers specialize in programming and development of new systems and applications of software. Modifying and designing applications and maintaining computer networks are often main functions of Software Engineers.

Find the Online Software Engineering School that fits your purposes here at http://www.schoolsgalore.com and begin taking steps to your new career in Software Engineering today.

Copyright 2006 – All Rights Reserved
Michael Bustamante, in association with Media Positive Communications, Inc. for SchoolsGalore.com

By: Michael Bustamante

Why Do We Need Software Engineering?

admin — Sun, 22 Nov 2009 21:47:18 +0000

To understand the necessity for software engineering, we must pause briefly to look back at the recent history of computing. This history will help us to understand the problems that started to become obvious in the late sixties and early seventies, and the solutions that have led to the creation of the field of software engineering. These problems were referred to by some as “The software Crisis,” so named for the symptoms of the problem. The situation might also been called “The Complexity Barrier,” so named for the primary cause of the problems. Some refer to the software crisis in the past tense. The crisis is far from over, but thanks to the development of many new techniques that are now included under the title of software engineering, we have made and are continuing to make progress.

In the early days of computing the primary concern was with building or acquiring the hardware. Software was almost expected to take care of itself. The consensus held that “hardware” is “hard” to change, while “software” is “soft,” or easy to change. According, most people in the industry carefully planned hardware development but gave considerably less forethought to the software. If the software didn’t work, they believed, it would be easy enough to change it until it did work. In that case, why make the effort to plan?

The cost of software amounted to such a small fraction of the cost of the hardware that no one considered it very important to manage its development. Everyone, however, saw the importance of producing programs that were efficient and ran fast because this saved time on the expensive hardware. People time was assumed to save machine time. Making the people process efficient received little priority.

This approach proved satisfactory in the early days of computing, when the software was simple. However, as computing matured, programs became more complex and projects grew larger whereas programs had since been routinely specified, written, operated, and maintained all by the same person, programs began to be developed by teams of programmers to meet someone else’s expectations.

Individual effort gave way to team effort. Communication and coordination which once went on within the head of one person had to occur between the heads of many persons, making the whole process very much more complicated. As a result, communication, management, planning and documentation became critical.

Consider this analogy: a carpenter might work alone to build a simple house for himself or herself without more than a general concept of a plan. He or she could work things out or make adjustments as the work progressed. That’s how early programs were written. But if the home is more elaborate, or if it is built for someone else, the carpenter has to plan more carefully how the house is to be built. Plans need to be reviewed with the future owner before construction starts. And if the house is to be built by many carpenters, the whole project certainly has to be planned before work starts so that as one carpenter builds one part of the house, another is not building the other side of a different house. Scheduling becomes a key element so that cement contractors pour the basement walls before the carpenters start the framing. As the house becomes more complex and more people’s work has to be coordinated, blueprints and management plans are required.

As programs became more complex, the early methods used to make blueprints (flowcharts) were no longer satisfactory to represent this greater complexity. And thus it became difficult for one person who needed a program written to convey to another person, the programmer, just what was wanted, or for programmers to convey to each other what they were doing. In fact, without better methods of representation it became difficult for even one programmer to keep track of what he or she is doing.

The times required to write programs and their costs began to exceed to all estimates. It was not unusual for systems to cost more than twice what had been estimated and to take weeks, months or years longer than expected to complete. The systems turned over to the client frequently did not work correctly because the money or time had run out before the programs could be made to work as originally intended. Or the program was so complex that every attempt to fix a problem produced more problems than it fixed. As clients finally saw what they were getting, they often changed their minds about what they wanted. At least one very large military software systems project costing several hundred million dollars was abandoned because it could never be made to work properly.

The quality of programs also became a big concern. As computers and their programs were used for more vital tasks, like monitoring life support equipment, program quality took on new meaning. Since we had increased our dependency on computers and in many cases could no longer get along without them, we discovered how important it is that they work correctly.

Making a change within a complex program turned out to be very expensive. Often even to get the program to do something slightly different was so hard that it was easier to throw out the old program and start over. This, of course, was costly. Part of the evolution in the software engineering approach was learning to develop systems that are built well enough the first time so that simple changes can be made easily.

At the same time, hardware was growing ever less expensive. Tubes were replaced by transistors and transistors were replaced by integrated circuits until micro computers costing less than three thousand dollars have become several million dollars. As an indication of how fast change was occurring, the cost of a given amount of computing decreases by one half every two years. Given this realignment, the times and costs to develop the software were no longer so small, compared to the hardware, that they could be ignored.

As the cost of hardware plummeted, software continued to be written by humans, whose wages were rising. The savings from productivity improvements in software development from the use of assemblers, compilers, and data base management systems did not proceed as rapidly as the savings in hardware costs. Indeed, today software costs not only can no longer be ignored, they have become larger than the hardware costs. Some current developments, such as nonprocedural (fourth generation) languages and the use of artificial intelligence (fifth generation), show promise of increasing software development productivity, but we are only beginning to see their potential.

Another problem was that in the past programs were often before it was fully understood what the program needed to do. Once the program had been written, the client began to express dissatisfaction. And if the client is dissatisfied, ultimately the producer, too, was unhappy. As time went by software developers learned to lay out with paper and pencil exactly what they intended to do before starting. Then they could review the plans with the client to see if they met the client’s expectations. It is simpler and less expensive to make changes to this paper-and-pencil version than to make them after the system has been built. Using good planning makes it less likely that changes will have to be made once the program is finished.

Unfortunately, until several years ago no good method of representation existed to describe satisfactorily systems as complex as those that are being developed today. The only good representation of what the product will look like was the finished product itself. Developers could not show clients what they were planning. And clients could not see whether what the software was what they wanted until it was finally built. Then it was too expensive to change.

Again, consider the analogy of building construction. An architect can draw a floor plan. The client can usually gain some understanding of what the architect has planned and give feed back as to whether it is appropriate. Floor plans are reasonably easy for the layperson to understand because most people are familiar with the drawings representing geometrical objects. The architect and the client share common concepts about space and geometry. But the software engineer must represent for the client a system involving logic and information processing. Since they do not already have a language of common concepts, the software engineer must teach a new language to the client before they can communicate.

Moreover, it is important that this language be simple so it can be learned quickly.

By: Edeh Chijioke

The Importance of Process in Software Engineering

admin — Sun, 22 Nov 2009 14:19:14 +0000

Energy is nebulous until it is directed by methods and processes. This is especially true when the energy is generated by the effort of individuals of a large corporation trying to accomplish an engineering task. Just as the circuits in analog appliances direct the flow of energy, methods and processes direct the flow of energy used to perform work in companies, large and small. The effectiveness of the methods developed for accomplishing tasks and the level of commitment employees have to the systems of an organization are key indicators of a company’s performance. No organization should attempt to produce a product or service without reliable systems directing their daily operations. Many organizations do attempt such feats and this is the cause of the quality problems in many companies today. Time constraints and the other demands are not acceptable excuses to sacrifice discipline.

Systems, processes, and methods always have a tremendous impact on the success or failure of I.T projects. Project success is not inevitable. Individuals performing software development roles in I.T. departments must be aware of the possibility of one or more steps in some adopted method being inappropriate for a particular application. This is where we find room for improvement and for new approaches to solving problems that have been learnt through experience.

Systems are broken down into manageable parts to give way to an entrepreneurial approach to development. This means that the process is broken down into tasks performed by team members.

Each team member takes responsibility for his or her work and develops their own strategic plan for implementing their work.

Those carrying out the SD roles inside organizations must have a commitment to the process that orchestrates how things are done on a daily basis, but at the same time they must not be so hardened by the process that inefficient procedures that hinder performance go unnoticed. There are occasions when some method that is part of a process is not applicable for some reason. There must be room for improvements regulated by guidelines that do not hinder progress.

If some analysis method is not able to be performed due to some constraint, the absence of this method should be recognized and excluded as soon as the constraint is seen in the initial requirements, for instance time constraints could make something impossible to perform within the time allocated for a task.

When effective processes are in place implementing solutions become trivial compared to what was initially presented to the engineering and I.T. teams. Request presented to the I.T department usually cannot be converted directly into engineering task. Management teams that are sources of information for things pertaining to new products or features don’t present requirements from a standpoint that engineers can use for functional design. The purpose of standard processes is to normalize these requirements, and once this happens the solutions are much easier to find.

An established I.T process digests the information presented to the department and distributes it to parts of the organization responsible for the work.

The work performed through this distributed knowledge is the same work that implements the solution to the problem. Those holding the software development roles are the organs of the system that performs the work. They must have a clear understanding of their responsibilities and should be committed to the process.

The process can be measured by how efficiently it solves a problem. Requirements coming into the I.T department creates a chaotic reaction if the processes used by the engineers are not powerful enough to regulate and direct how the information is moved throughout department. If the procedures are weak, we would observe redundant information, overlapping requirements and changes to requirements that results in complex dependencies.

At the core of the data received by the I.T department is the requirement. The normalization of the data sent to the I.T department must be done effectively enough to avoid the weaknesses mentioned above and the result used to create more granular functional designs. In I.T departments these requirement documents contain the information needed to find application types such as C++ modules, classes and abstractions.

Sometimes there are no established I.T processes in place. I have worked for more than one organization that believed that a formal development process was not necessary because their projects were either not large or complex enough, or that the engineers were so talented that they could work without processes that regulated development work.

I was criticized for attempting to implement formal engineering strategies even for my own work. The result of not having a system in place was chaos in every case, bad quality and performance, but still it appeared that in many firms this chaos was accepted as the normal state of the I.T department.

Moreover, in smaller companies, upper management teams (mainly those managers involved in process control and development) lost control and authority of the service and products offered by the company and the engineers were pretty much in control of everything.

Systems that move information around within organizations and how they are designed is a firm indicator of upper management’s desire to maintain control of organizational operations.

When knowledge is not distributed properly because of poor process or lack of commitment, upper management will lose control because they will not be able to track performance, understand system design or coordinate activities within the company.

For example, each Design Document contains the knowledge needed by management to set effective milestones and targets that are concrete enough to measure performance. By not requiring that the engineering department work within a system that produces and distributes their development data throughout the company, the company essentially turns all control of engineering over to the developers.

This is not good, because every department should be open to checks and cross checks by outside controllers. The result of such inefficiencies is that upper management cannot make good decisions about the design, implementation or future direction of the systems. In most cases the organizational process is relied on to produce the data that is the locus of the decision making process.

In every case the time you spend dealing with problems due to a bad processes will be more costly than the time taken to develop formal procedures and follow them correctly. To some extent engineers must change who they are in order to accept new ways of doing things.

To end this I would like to say that, systems take on a personality that resembles the implementer. Standard procedures keep the companies personality or character on the systems implementation not the personality of individual developers.

By: Ellis Smith

Preparing for Software Engineering Job Interview

admin — Thu, 05 Nov 2009 23:59:28 +0000

I have received several requests about what to expect during the interview process for a software engineering position. Based on my experience, the interview process typically occurs in three phases. So don’t be surprised that this may seem like a lengthy process, it is.

The first interview is normally conducted by human resources or a general staff person filter through resumes. During this initial contact, the interviewer is looking for basic information. Questions will include:

How did you hear about this position? This is where they determine what career marketing strategy they are using really works, i.e., Careerbuilder.com, Monster.com, Dice.com, corporate website, friend, etc. Are you willing to relocate? Although there was an initial push for telecommuter hires, it appears more jobs are being filled which require the new hire to report to a physical office location. So much for modern technology. More jobs are being moved to lower overhead locations. They need to know before they waste further resources, if you are serious about moving to the middle of nowhere for this job. Can you work in the United States? Of course, this question is specific to American readers, but they need to know you work status. How soon can you start? Be honest on this one. Don’t be too eager to take a job, when you have to tie up a lot of loose ends in relocating. They will expect something in excess of two weeks. You will have to consider selling your house or getting out of a lease, moving your lifetime collection of whatever, informing your current employer and completing any task you are currently working on for them. I believe 4 weeks is a minimum response in most cases.

The second interview will be conducted by someone with a technical background. At this point, you has expressed interest in a position and have shown a willingness to relocate to their facility. Now comes the part where they try to determine if you will be an asset to them or a good fit for their team dynamics. Here are some questions you are likely to hear:

What is your current job title? Although you may not currently hold a software engineering job title, there is still hope of landing a software engineering position. The interviewer is trying to make sense from the skills you put down on your resume versus what skills are required of your current job position. Do you have any experience with team-based work environments? You may think this is a simple type of question to be asked, however, many people do not have to interact with other individuals to complete work tasks. As a software engineer, you will be required to interface with other team members, usually on a daily basis. Team work is not for everyone. If you have the type of personality that makes team-based work or decisions difficult, you should be honest with yourself. Otherwise, you may land a position you regret taking. Are you willing to relocate? Yes, this question was asked in the first interview. The prospective company needs to know you intention for inquiring for this position. Companies receive a ton of applications from a variety of sources with many people applying just to test the market. Again, be honest about your willingness to relocate. What type of programming experience do you have? Some companies may be in need of a language specific applicant, others may not. Be honest about your abilities, highlight your attributes and state your limitations.

The third phase of the interview process will likely come in the form of a skills test. This interview is prefaced on the fact that you have the requisite background they seek, and your willingness to work where the job is. The test may come in a face to face format, or many companies are using a proctored test format. For those unfamiliar with a proctored test format, essentially it requires that a neutral party is present to administer the test and to verify that time restraints are met and no reference materials are used. The proctored test can be given at a local library or university. The prospective company will handle the logistics of this arrangement and to see the test is delivered and received. Listed below are some links in reference to what to expect on the attitude test:

Interview questions for tech companies Preparing for a Software Engineering Interview Microsoft Interview Questions [http://www.sellsbrothers.com/fun/msiview/#Questions_for_Testers]

By: Rick Huey