Chapter 5
Software Engineering Practice:
his section lists the generic framework (communication, planning, modeling, construction, and deployment) and umbrella (tracking, risk management, reviews, measurement, configuration management, re usability management, work product creation, and product) activities found in all software process models.
The Essence of Practice:
The essence of software engineering practice is as follows:
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)
- Understand the problem (communication and analysis).
- Who are the stakeholders?
- What are the unknowns? “Data, functions, features to solve the problem?”
- Can the problem be compartmentalized? “Smaller that may be easier to understand?
- Can the problem be represented graphically? Can an analysis model be created?
- Plan a solution (modeling and software design).
- Have you seen a similar problem before?
- Has a similar problem been solved? If so, is the solution reusable?
- Can sub-problems be defined?
- Can you represent a solution in a manner that leads to effective implementation?
- Carry out the plan (code generation).
- Does the solution conform to the plan?
- Is each component part of the solution probably correct?
- Examine the result for accuracy (testing and quality assurance).
- Is it possible to test each component part of the solution?
- Does the solution produce results that conform to the data, functions, features, and behavior that are required?
General/core principles:
1) The Reason It All Exists: Provide value to the customer and the user. If you can’t provide value, then don’t do it.
2) 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 facilitates having a more easily understood and easily maintained system.
3) Maintain the product and project “vision.” A clear vision is essential to the success of a software project. Without one, a project almost unfailingly ends up being “of two [or more] minds” about itself. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws .
4) What you produce, others will consume. Always specify, design, and implement knowing someone else have to understand what you are doing.
5) Be open to the Future. Never design yourself into a corner. Always ask “what if,” and prepare yourself for all possible answers by creating systems that solve the general problem, not just the specific one.
6) Plan Ahead for Reuse. Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.
7) Think! This last Principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right.
Core Principals that guide process:
Software engineering is guided by a collection of core principles that help in the application of a meaningful software process and the execution of effective software engineering methods.
Following are the core principles that guide process and practice:
Principles That Guide Process:
1) Principle 1. Be agile: Whether the process model you choose is prescriptive or agile, the basic tenets of agile development should govern your approach.
2) Principle 2. Focus on quality at every step. The exit condition for every process activity, action, and task should focus on the quality of the work product that has been produced.
3) Principle 3. Be ready to adapt. Process is not a religious experience, and dogma has no place in it. When necessary, adapt your approach to constraints imposed by the problem, the people, and the project itself.
4) Principle 4. Build an effective team. Software engineering process and practice are important, but the bottom line is people. Build a self-organizing team that has mutual trust and respect.
5) Principle 6. Manage change The approach may be either formal or informal, but mechanisms must be established to manage the way changes are requested, assessed, approved, and implemented.
6) Principle 7. Assess risk. Lots of things can go wrong as software is being developed. It’s essential that you establish contingency plans. Some of these contingency plans will form the basis for security engineering tasks
Core Principals that guide practice:
1) Principle 1. Divide and conquer Stated in a more technical manner, analysis and design should always emphasize separation of concerns (SoCs). A large problem is easier to solve if it is subdivided into a collection of elements (or concerns).
2) Principle 2. Understand the use of abstraction. At its core, an abstraction is a simplification of some complex element of a system used to communicate meaning in a single phrase. When we use the abstraction spreadsheet, it is assumed that you understand what a spreadsheet is, the general structure of content that a spreadsheet presents, and the typical functions that can be applied to it.
3) Principle 3. Strive for consistency. Whether it’s creating an analysis model, developing a software design, generating source code, or creating test cases, the principle of consistency suggests that a familiar context makes software easier to use.
4) Principle 4. Focus on the transfer of information. Software is about information transfer—from a database to an end user, from a legacy system to a Web App, from an end user into a graphic user interface (GUI), from an operating system to an application, from one software component to another the list is almost endless.
5) Principle 5. Build software that exhibits effective molecularity. Separation of concerns (Principle 1) establishes a philosophy for software. Molecularity provides a mechanism for realizing the philosophy. Any complex system can be divided into modules (components), but good software engineering practice demands more. Molecularity must be effective.
Communication Practices:
1) Principle 1. Listen. Try to focus on the speaker’s words, rather than formulating your response to those words. Ask for clarification if something is unclear, but avoid constant interruptions.
2) Principle 2. Prepare before you communicate. Spend the time to understand the problem before you meet with others. If necessary, do some research to understand business domain jargon.
3) Principle 3. Someone should facilitate the activity. Every communication meeting should have a leader (a facilitator) to keep the conversation moving in a productive direction, (2) to mediate any conflict that does occur, and (3) to ensure that other principles are followed
4) Principle 4. Face-to-face communication is best. But it usually works better when some other representation of the relevant information is present.
5) Principle 5. Take notes and document decisions. Things have a way of falling into the cracks. Someone participating in the communication should serve as a “recorder” and write down all important points and decisions.
Planning Practices:
The following principles always apply:
1) Principle 1. Understand the scope of the project. It’s impossible to use a road map if you don’t know where you’re going. Scope provides the software team with a destination.
2) Principle 2. Involve stakeholders in the planning activity. Stakeholders define priorities and establish project constraints. To accommodate these realities, software engineers must often negotiate order of delivery, time lines, and other project-related issues.
3) Principle 3. Recognize that planning is iterative. A project plan is never engraved in stone. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes.
4) Principle 4. Estimate based on what you know. The intent of estimation is to provide an indication of effort, cost, and task duration, based on the team’s current understanding of the work to be done. If information is vague or unreliable, estimates will be equally unreliable.
5) Principle 5. Consider risk as you define the plan. If you have identified risks that have high impact and high probability, contingency planning is necessary.
6) Principle 6. Be realistic. People don’t work 100 percent of every day. Noise always enters into any human communication. Omissions and ambiguity are facts of life.
Modeling Practices:
1) Principle 1. The primary goal of the software team is to build software, not create models. create models. Agility means getting software to the customer in the fastest possible time.
2) Principle 2. Travel light—don’t create more models than you need. Every model that is created must be kept up-to-date as changes occur. More importantly, every new model takes time that might otherwise be spent on construction (coding and testing).
3) Principle 3. Build models in a way that makes them amenable to change. Assume that your models will change, but in making this assumption don’t get sloppy.
4) Principle 4. Be able to state an explicit purpose for each model that is created. Every time you create a model, ask yourself why you’re doing so. If you can’t provide solid justification for the existence of the model, don’t spend time on it.
5) Principle 5. Adapt the models you develop to the system at hand. It may be necessary to adapt model notation or rules to the application; for example, a video game application might require a different modeling technique than real-time, embedded software that controls an automobile
6) engine.
Principle 6. Get feedback as soon as you can. Every model should be reviewed by members of the software team. The intent of these reviews is to provide feedback that can be used to correct modeling mistakes, change misinterpretations, and add features or functions that were inadvertently omitted.
Analysis Modeling Principles:
1) The information domain of a problem must be represented and understood. The information domain encompasses the data that flow into the system (end-users, other systems, or external devices), the data that flow out of the system and the data stores that collect and organize persistent data objects.
2) Represent software functions. Functions can be described at many different levels of abstraction, ranging from a general statement of purpose to a detailed description of the processing elements that must be invoked.
3) Represent software behavior. The behavior of the S/W is driven by the interaction with the external environment. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion (or hierarchical).
4) The analysis task should move from essential information toward implementation detail. Analysis begins by describing the problem from the end-user perspective. The ”essence” of the problem is described without any consideration of how a solution will be implemented.
Design Modeling Principles:
1) Design
must be traceable to the analysis model.
The
analysis model describes the information domain of the problem, user visible
functions, system behavior, and a set of analysis classes that package business
objects with the methods that service them.
The design model translates this information into an architecture: a set of
subsystems that implement major functions, and a set of component-level designs
that are the realization of analysis class.
2) Always consider architecture. S/W architecture is the skeleton of the system to be built. Only after the architecture is built should the component-level issues should be considered.
3) Focus on the design of data as it is as important as a design. Data design is an essential element of t architectural design.
4) Interfaces (both user and internal) must be designed. A well designed interface makes integration easier and assists the tester in validating component functions.
5)
Component-level design should
exhibit functional independence.
The functionality that is delivered by a component should be cohesive-
that is, it should focus on one and only one function.
Components should be loosely coupled to one another and to the external
environment. Coupling is achieved in many ways – via a
component interface, by messaging through global data. Coupling should be
kept as low as is reasonable. As the level of coupling increases, error
propagation also increases and the overall maintainability of the system
decreases.