Monday, September 15, 2008

SOFTWARE ENGINEERING PRACTICE

People who create computer software practice the art or craft or discipline that is software engineering. But what is software engineering “practice”? in a generic sense, practice is a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily basis. Practice allows managers to manage software projects and software engineers to build computer programs. Practice populates a software process model with the necessary technical and management how-to’s to get the job done. Practice transforms a haphazard unfocused approach into something that is more organized, more effective, and more likely to achieve success.

The essence of practice

How to solve it, engineers outlined the essence of problem solving, and consequently, the essence of software engineering practice.

1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

Core principles

The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought” throughout this book we discuss principles at many different levels of abstraction. Some focus on software engineering as a whole, others consider a specific generic framework activity (e.g., customer communication), and still others focus on software engineering actions (e.g., architectural design) or technical tasks (e.g., write a usage scenario). Regardless of their level of focus, principles help us establish a mind set for solid software engineering practice. They are important for that reason.

First principle: The reason it all exists

A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before nothing a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: does this add real value to the system? If the answer is no, don’t do it. All other principles support this one.

The second principle: Kiss (Keep it simple, stupid)
Software design is not a haphazard process. There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilities having a more easily understood, and easily maintained system. This is not to say that features, even internal features, should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simple ones. Simple also does not mean “quick and dirty.” In fact, it often takes a lot of thought and work over multiple iterations to simplify. The pay-off is software that is more main tainable and less error prone.
The third principle: Maintain the vision

A clear vision is essential to the success of a software project. Without one, a project almost unfailingly ends up being “of two minds” about itself. Without conceptual integrity, a system threatens to become a patchwork of incompatible design, held together by the wrong kind of screws.
Compromising the architectural vision of a software system weakens and will eventually break even a well-designed system. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.
The fourth principle: What you produce, other will consume
Seldom is an industrial-strength software system constructed and used in a vacuum. In some way or other, someone else will use, maintain, document, or other wise depend on being able to understand your system. So always specify, design, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those who must maintain and extend the system. Someone may have to debug the code write, and that makes them a user of your code. Making their job easier adds value to the system.

No comments: