The profession of a Software Engineer is geared towards adopting the best practices in building software applications. It is important that engineers should know what practices are utilized by the industry especially those specialized skills that they need to learn in order to leverage their capability to achieve their goals in development.
Close user involvement
Users are the primary author of the functional and non-functional requirements known as product features. It is therefore essential for a software engineer to learn how to interact with users during the course of development. They should develop their communication and negotiation skills in situations where a certain requirement needs to be changed. Engineers need to be able to translate technical requirements into business requirements in order for the users to understand and validate them. In the long run, the users will be the one using the system.
Proper project management
Project management is essential for a software engineer because they normally work in teams. There can be problems with communication, personality conflicts, cost and schedule overruns, and scope creep. They need to know how to allocate resources for every activity in a work breakdown structure. They need to identify the possible risks and define contingency plans in cases where a risk becomes a problem especially during project execution. Engineers need to know how to interact with the higher management to negotiate added resources and make decisions on some constraints in the project.
Use of well-defined processes
Engineers are known to be problem solvers and analytical thinkers. However, one key aspect of an engineer is the utilization of defined processes in the creation and building of a software product. It then follows the principle of "A quality process produces a quality product". There is no such thing as unstructured practices because engineers are responsible with the products they build for customers. Even Agile Development has a process in building software. The goal is always to satisfy the needs and demands of clients through a systematic and disciplined way of doing things.
In general, engineers need to be more committed towards delivering quality products to customers. They need to learn how to build and continuously improve these practices. It is the one thing that differentiates them with other IT Professionals in the field of software development.
Saturday, June 6, 2009
Friday, June 5, 2009
Software Engineering: Art or Science?
In the late 1960's, software engineering was intended to address the problem of software crisis. Software has becoming large and complex that the traditional practices of computer programming was not enough to address changing requirements, increasing size of applications, and other factors that made it too complicated by just doing programming.
The art of building software applications need not follow any set of procedures. The artist can develop applications dependent on how he perceived it and what he would think can be a good product. No consultations can be made from experts about whether it can address a certain need or a client to satisfy. In the building of a software product, there can be a set of desired properties that should be defined and mostly, clients or customers are the ones who demand it. For an artist, it might be good to reconsider market trends, target markets and economic issues beforehand.
However, software engineering as a science means that there should be a pre-defined set of theories and proven development paradigms to consider in development. A developer can either use Agile or Rational Unified Process because it has been used by the industry for years now. Although there might be issues whether they can be adaptable to projects, it is still the prerogative of the developer to make decisions. As a science, development can be more suitable for applications which are mission-critical and cost millions of dollars.
Software engineering can be both an art and science in some way. Innovating software products can be an art because the artist tends to look for ways to make it more appealing to the target market whereas it can be science because it can somehow follow a development process or paradigms to ensure that the product has achieved its pre-defined properties as validated by clients and customers.
The art of building software applications need not follow any set of procedures. The artist can develop applications dependent on how he perceived it and what he would think can be a good product. No consultations can be made from experts about whether it can address a certain need or a client to satisfy. In the building of a software product, there can be a set of desired properties that should be defined and mostly, clients or customers are the ones who demand it. For an artist, it might be good to reconsider market trends, target markets and economic issues beforehand.
However, software engineering as a science means that there should be a pre-defined set of theories and proven development paradigms to consider in development. A developer can either use Agile or Rational Unified Process because it has been used by the industry for years now. Although there might be issues whether they can be adaptable to projects, it is still the prerogative of the developer to make decisions. As a science, development can be more suitable for applications which are mission-critical and cost millions of dollars.
Software engineering can be both an art and science in some way. Innovating software products can be an art because the artist tends to look for ways to make it more appealing to the target market whereas it can be science because it can somehow follow a development process or paradigms to ensure that the product has achieved its pre-defined properties as validated by clients and customers.
Software Engineer: Issues and Challenges
Software engineers in the industry are faced with different challenges in building quality software applications. Although these challenges shaped the way engineers build, they pose a great threat towards satisfying the needs and expectations of clients. Here are some of those biggest challenges:
(1) Complexity
The evolution of technology has made software applications becoming larger and complex. Unlike before wherein software is encapsulated in complex algorithms and pseudo codes, external factors including project stakeholders contribute to it. Stakeholders in the project have varying demands that it became impossible to achieve project success. In addition, clients nowadays are more involved in product creation and they are more demanding of the features for a product. Scope creep normally happens if changes to requirements cannot be tracked and evaluated.
(2) Unrealistic estimates
The complexity of an application makes it hard for an engineer to accurately estimate the schedule and project resources. The latest FBI Virtual Case File is an example of it. Just imagine the case wherein software is paid for but not delivered on time. In addition to that, changes to requirements contributed to it and to think that they can't be avoided. The absence of a mature process to define measurement of efforts and productivity significantly affects the prediction of the actual effort exerted during project execution.
(3) Non-productive costs
Crosby said that in everything we do, we need to "do it right the first time" to eliminate the cost of doing it again. For years, engineers tend to do repeat the same mistakes over and over again. We know that it is very expensive to fix the code when it was already delivered to the client and later on, reported that it had defects on it rather than fixing it early in the development process. Due to immaturity of organisations towards best practices and process maturity, the software processes remained unstructured and undefined.
Though there can be many challenges in building a software product, the above mentioned were just a few of them. It is essential to understand and assess their risks to your current software projects. The question that we need to ask ourselves is: why is it that we don't have time to do things right the first time but we always have time to do it again?
(1) Complexity
The evolution of technology has made software applications becoming larger and complex. Unlike before wherein software is encapsulated in complex algorithms and pseudo codes, external factors including project stakeholders contribute to it. Stakeholders in the project have varying demands that it became impossible to achieve project success. In addition, clients nowadays are more involved in product creation and they are more demanding of the features for a product. Scope creep normally happens if changes to requirements cannot be tracked and evaluated.
(2) Unrealistic estimates
The complexity of an application makes it hard for an engineer to accurately estimate the schedule and project resources. The latest FBI Virtual Case File is an example of it. Just imagine the case wherein software is paid for but not delivered on time. In addition to that, changes to requirements contributed to it and to think that they can't be avoided. The absence of a mature process to define measurement of efforts and productivity significantly affects the prediction of the actual effort exerted during project execution.
(3) Non-productive costs
Crosby said that in everything we do, we need to "do it right the first time" to eliminate the cost of doing it again. For years, engineers tend to do repeat the same mistakes over and over again. We know that it is very expensive to fix the code when it was already delivered to the client and later on, reported that it had defects on it rather than fixing it early in the development process. Due to immaturity of organisations towards best practices and process maturity, the software processes remained unstructured and undefined.
Though there can be many challenges in building a software product, the above mentioned were just a few of them. It is essential to understand and assess their risks to your current software projects. The question that we need to ask ourselves is: why is it that we don't have time to do things right the first time but we always have time to do it again?
I am a Software Engineer, not a Computer Programmer!
There had been a misconception that a software engineer is just the same as a computer programmer. In an advertisement, the advertiser would say that they are looking for a software engineer but if you just examine the contents of the job description, what they are looking for is a computer programmer position (e.g. who can code and test using C#, Java, etc).
The phases of building software applications normally consist of requirements, design, code, and testing. These four (4) major phases of software development are performed by people with varying skills, for instance, systems analyst for requirements, technical architect for design, computer programmer for coding and software tester for performing tests. As you can see, the computer programmer is mainly concerned with, say, low-level design to code and possible unit testing in a certain piece of software. It would be hard for a programmer to act as a systems analyst, for example, because of his inability to interact with clients for defining business requirements and their focus is more technical in nature.
On the other hand, software engineers are mainly concerned with the whole software development process. It is assumed that a software engineer understands customer’s problems and transforms it into a software application that can somehow address those problems. That is what "engineering" in software engineering really means. He should understand the requirements process, design methodologies, program codes, testing methodologies and even the maintenance of different software applications. He can even lead a team of developers to build a software product because of his orientation towards software project management.
The roles we chose in development are dependent on the skills we have and what we love to do. That is why, it is important to make a distinction between these two fields. It can prevent overlapping of responsibilities that can affect the quality of the software products we delivered to customers. Software applications are becoming larger and complex that a software engineer is needed. Programmers are not enough. In order to deliver the product that the customer really wanted, it is important to understand the customer’s business environment in order to solve the real problem of customers.
The phases of building software applications normally consist of requirements, design, code, and testing. These four (4) major phases of software development are performed by people with varying skills, for instance, systems analyst for requirements, technical architect for design, computer programmer for coding and software tester for performing tests. As you can see, the computer programmer is mainly concerned with, say, low-level design to code and possible unit testing in a certain piece of software. It would be hard for a programmer to act as a systems analyst, for example, because of his inability to interact with clients for defining business requirements and their focus is more technical in nature.
On the other hand, software engineers are mainly concerned with the whole software development process. It is assumed that a software engineer understands customer’s problems and transforms it into a software application that can somehow address those problems. That is what "engineering" in software engineering really means. He should understand the requirements process, design methodologies, program codes, testing methodologies and even the maintenance of different software applications. He can even lead a team of developers to build a software product because of his orientation towards software project management.
The roles we chose in development are dependent on the skills we have and what we love to do. That is why, it is important to make a distinction between these two fields. It can prevent overlapping of responsibilities that can affect the quality of the software products we delivered to customers. Software applications are becoming larger and complex that a software engineer is needed. Programmers are not enough. In order to deliver the product that the customer really wanted, it is important to understand the customer’s business environment in order to solve the real problem of customers.
Thursday, June 4, 2009
Where is "Engineering" in Software Engineering?
For years, there had been debates about where is "engineering" in software engineering when in fact; engineering software is mainly concerned with building reliable and cost-effective software applications. If we examine the term "engineering", it focuses mainly on the application of scientific knowledge in the creation and building of cost-effective solutions in the service of mankind.
In building software applications, it also undergo the systematic approaches (like engineering) of identifying and analysing the business problem, identify possible alternatives specifically on what technologies can be used, conducting evaluation of the appropriate solutions and later on design and implement the software solutions.
In engineering the software product, it encompasses the issue of just building and constructing it. Rather, it should be aligned with addressing the business goals through its achievement of the desired set of product properties. Normally, these requirements are defined by key stakeholders in the project. In software terms, they are considered to be functional and non-functional requirements which can evolve and subjected to changes during actual project execution.
Software engineers use standards and design handbooks as with engineering. They are represented by IEEE Standards, CMM/SPICE, IEEE/EIA 12207, and many others to guide the execution of software processes in the project. The release of Software Engineering Code of Ethics by IEEE-CS & ACM guides the practice of software engineers in dealing with stakeholders and colleagues during software projects.
As with engineers, software engineers design and make choices of an appropriate architecture of systems. It covers the selection of appropriate technologies to address the business problems of clients and customers. There were too many database technologies now and it would be the responsibility of the software engineer to make design decisions of what database technology will be used to achieve the business goals of stakeholders. In any product development, there can be tradeoffs to cost, schedule and scope but it should be managed by engineers by making the correct decisions.
The "engineering" side of software engineering can be clearly justified as long as those "would-be" software engineers understand the "engineering practice" in development. When you engineer the software product, the issue of looking towards "systematic, disciplined, and quantifiable" should be the main attributes of your practice. Product development gears towards achieving software quality and it can be achieved only if it is done the proper way. Although quality is subjective, it doesn't mean that it can't be measured.
In building software applications, it also undergo the systematic approaches (like engineering) of identifying and analysing the business problem, identify possible alternatives specifically on what technologies can be used, conducting evaluation of the appropriate solutions and later on design and implement the software solutions.
In engineering the software product, it encompasses the issue of just building and constructing it. Rather, it should be aligned with addressing the business goals through its achievement of the desired set of product properties. Normally, these requirements are defined by key stakeholders in the project. In software terms, they are considered to be functional and non-functional requirements which can evolve and subjected to changes during actual project execution.
Software engineers use standards and design handbooks as with engineering. They are represented by IEEE Standards, CMM/SPICE, IEEE/EIA 12207, and many others to guide the execution of software processes in the project. The release of Software Engineering Code of Ethics by IEEE-CS & ACM guides the practice of software engineers in dealing with stakeholders and colleagues during software projects.
As with engineers, software engineers design and make choices of an appropriate architecture of systems. It covers the selection of appropriate technologies to address the business problems of clients and customers. There were too many database technologies now and it would be the responsibility of the software engineer to make design decisions of what database technology will be used to achieve the business goals of stakeholders. In any product development, there can be tradeoffs to cost, schedule and scope but it should be managed by engineers by making the correct decisions.
The "engineering" side of software engineering can be clearly justified as long as those "would-be" software engineers understand the "engineering practice" in development. When you engineer the software product, the issue of looking towards "systematic, disciplined, and quantifiable" should be the main attributes of your practice. Product development gears towards achieving software quality and it can be achieved only if it is done the proper way. Although quality is subjective, it doesn't mean that it can't be measured.
Subscribe to:
Posts (Atom)