Waterfall life cycle model, considered to be one of the traditional life cycle models that has identified different stages when building software applications. It starts off with requirements, then design, implementation, testing and lastly, maintenance. Every phases of the waterfall should be completed before moving into the next phase. An entry and exit criteria is used to assess the completeness of each phase. I would say that this approach to software development can still be applied to the current practice of building software applications.
Due to the inherent complexity of software applications, new development paradigms (rather than just life cycle models such as spiral, prototyping, etc.) have emerged to cater for changing requirements of customers in which the traditional waterfall model cannot address. One of these was the Rational Unified Process (RUP), a heavyweight process aligned to SEI's Capability Maturity Model (CMM). It consists of phases, namely; inception, elaboration, construction and transition. However, due to its nature, it was intended for large scale projects wherein software processes should be defined in development. Another is the birth of Agile Development consisting of Extreme Programming (XP), Test-Driven Development (TDD), Scrum, and many others. Agile processes are more flexible in terms of handling software processes and more focused on the Agile Manifesto as a baseline for its practice. Nowadays, agile practices are becoming widespread and more software companies are using it.
In this new era of computing, the same software life cycle processes (see IEEE/EIA 12207.0 Standards for details) were used for development. Every product needs to have pre-defined set of requirements or features. Then, these features will be realized in the design and implementation using different technologies and tools. After which, it will be subjected to software testing as a means of quality control before deploying it to customer. Software applications now are developed iteratively (rather than linearly as waterfall) to address the changing needs and demands of customers (rather than a fixed set of requirements). The main foundation is still waterfall life cycle. One thing is certain, software companies have their own way of building software for different types of software projects and Waterfall is one of them...still.
Wednesday, June 17, 2009
Sunday, June 14, 2009
Reading Materials for SE Professionals
There are lots of resources in the web for software engineering materials to read on. Normally, I don't use only one book for readings and I am very selective about what I read especially in terms of how they practice software engineering as a whole.
For a book, the classic reference that you can have is from Roger S. Pressman in his book entitled "Software Engineering: A Practitioner's Approach" which is currently on its 7th Edition. Pressman's website can be found here. He has provided software engineering resources there that can be a useful material for learning. Another classic SE book is from Ian Sommerville in his book entitled "Software Engineering" which is currently on its 8th edition. As with Pressman, Sommerville's book has been published for software engineering professionals even when software engineering was just considered as a best practice for developing software. What's good with his website was that all the chapters of his book in slide presentations and pdf formats can be downloaded for free. I don't know why he did it but it was really good. You can check his new website here.
One of my favourites for SE readings was the book of Karl Wiegers entitled "Creating a Software Engineering Culture". It was really a good book because it emphasizes the essence of building an SE culture where everybody is committed towards building quality into the product. It has also a lot of strategies for imposing software engineering strategies and practices in software engineering organizations. You can visit him at Process Impact. Another is the book of Steve McConnell entitled "Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers" which illustrates how software development should be dealt with and some issues with regards to how people build software products. Visit his site here. I would really recommend you to read it.
For some internet resources, you can apply for membership with the IEEE and IEEE - Computer Society to subscribe to various technical magazines and journals. Every month, they had this Computer Magazines which can be interesting to read for new developments in Computing. Another is the IEEE Software which is available bi-monthly. It is a very good source for new knowledge and interesting articles. You can visit IEEE-CS for details. The IEEE-CS developed this IEEE Software Engineering Online which is patterned to SE Body of Knowledge. What they did was to compile all available resources by SE Knowledge Areas such as requirements, design, construction, etc. The website is here for details.
Well, I guess those are some of my favourite resources for software engineering theory and practice. Although it can be technical, you can try visiting the Software Engineering Institute here. The works of Watts Humphrey towards emphasizing the software process framework (PSP, TSP, & CMM) in building software greatly contributed to how SE has evolved through the years. I would only suggest that you need to criticize what you read on the net as they may sometimes lead you to a different perspective of how Software Engineering is practiced.
For a book, the classic reference that you can have is from Roger S. Pressman in his book entitled "Software Engineering: A Practitioner's Approach" which is currently on its 7th Edition. Pressman's website can be found here. He has provided software engineering resources there that can be a useful material for learning. Another classic SE book is from Ian Sommerville in his book entitled "Software Engineering" which is currently on its 8th edition. As with Pressman, Sommerville's book has been published for software engineering professionals even when software engineering was just considered as a best practice for developing software. What's good with his website was that all the chapters of his book in slide presentations and pdf formats can be downloaded for free. I don't know why he did it but it was really good. You can check his new website here.
One of my favourites for SE readings was the book of Karl Wiegers entitled "Creating a Software Engineering Culture". It was really a good book because it emphasizes the essence of building an SE culture where everybody is committed towards building quality into the product. It has also a lot of strategies for imposing software engineering strategies and practices in software engineering organizations. You can visit him at Process Impact. Another is the book of Steve McConnell entitled "Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers" which illustrates how software development should be dealt with and some issues with regards to how people build software products. Visit his site here. I would really recommend you to read it.
For some internet resources, you can apply for membership with the IEEE and IEEE - Computer Society to subscribe to various technical magazines and journals. Every month, they had this Computer Magazines which can be interesting to read for new developments in Computing. Another is the IEEE Software which is available bi-monthly. It is a very good source for new knowledge and interesting articles. You can visit IEEE-CS for details. The IEEE-CS developed this IEEE Software Engineering Online which is patterned to SE Body of Knowledge. What they did was to compile all available resources by SE Knowledge Areas such as requirements, design, construction, etc. The website is here for details.
Well, I guess those are some of my favourite resources for software engineering theory and practice. Although it can be technical, you can try visiting the Software Engineering Institute here. The works of Watts Humphrey towards emphasizing the software process framework (PSP, TSP, & CMM) in building software greatly contributed to how SE has evolved through the years. I would only suggest that you need to criticize what you read on the net as they may sometimes lead you to a different perspective of how Software Engineering is practiced.
Saturday, June 6, 2009
Essential Skills for a Software Engineer
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.
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.
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)