MBA management

Software Engineering Practices and Software Modeling Practices topics:

SOFTWARE ENGINEERING PRACTICE


In this part of “software engineering; a practitioner’s approach” you’ll learn about the principles, concepts, and methods that comprise software engineering practice. These questions are addressed in the chapters that follows:

• What concepts and principles guide software engineering practice?
• How does system engineering lead to effective engineering?
• What is requirements engineering, and what are the underlying concepts that lead to good requirements analysis?
• How is thee analysis model created, and are its elements?
• What is design engineering, and what are the underlying concepts that lead to good design?
• What concepts, models and methods are used to create architectural, interface, and component level designs?
• What strategies are applicable to software testing?
• What methods are used to design effective test cases?
• What measures and metrics can be used to assess the quality of analysis and design models, source code and test cases?

Once these questions are answered you’ll be better prepared to apply software engineering practice.

In a book that explores the lives and thoughts of software engineers, Ellen Ullman depicts a slice of life as she relates the thoughts of practitioner under pressure.

I have no idea what time it is. There are no windows in this office and no clock, only the blinking red LED display of a microwave, which flashes 12.00, 12.00, 12.00, 12.00. Joel and I have been programming for days. We have a bug, a stubborn demon of a bug, so the red pulse no-time feels right, like a read-out of our brains, which have somehow synchronized themselves at the same blink rate…..

What are we working on?..... The details escape me just now. We may be helping poor sick people or tuning a set of low- level routines to verify bits on a distributed database protocol- I don’t care. I should care very much why and for whom and for what purpose I am writing software. But just now: no. I have passed through a membrane where that real world and its uses no longer matter. I am a software engineer…..

A dark image of software engineering practice to be sure, but upon reflection, many of the readers of this book will be able to relate to it.

People who create computer software practice the art of craft or discipline that is software engineering. But what it 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 get the job done. Practice transforms a haphazard unfocused approach into something that is more organized, more effective and more likely to achieve success. Some writers argue for one of these terms to the exclusion of the others. In reality, software engineering is all three.

What is it? Practice is a broad array of concepts, principles, methods, and tools that you must consider as software planned and developed. It represents the details-the technical considerations and how to—that are below the surface of the software process: the things that you’ll need to actually build high-quality computer software.

Who does it? The practice of software engineering is applied by software engineers and their managers.

Why is it important? The software process provides everyone involved in the creation of a computer-based system or product with a road map for getting to a destination successfully. Practice provides you with the detail you’ll need to drive along the road. It tells you where the bridges, the roadblocks, and the forks are located. It helps you understand the concepts and principles that must be understood and followed to drive safely and rapidly. It instructs you on how to drive, where to slow down, and where to speed up. In the context of software engineering, practice is what you do day in and day out as software evolves from an idea to a reality.

What are the steps? Three elements of practice apply regardless of the process models that is chosen. They are: concepts, principles, and methods. A fourth element of practice—tools—supports the application of methods.

What is the work product? Practice encompasses the technical activities that produce all work products that are defined by the software process model that has been chosen.

We introduced a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities—communication, planning, modeling,, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work, But how does the practice of software engineering fit in? In the sections that follow, we consider the generic concepts and principles that apply to framework activities. The reader is encouraged to revisit relevant sections within this chapter as specific software engineering methods and umbrella activities are discussed later in this book.

The essence Practice


In a classic book, How to Solve It, written before modern computes existed, gorge Polya 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).

In the context of software engineering, these common sense steps lead to a series of essential questions.

Understand the problem:
• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, features, and behavior are required to properly solve the problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand?

Can the problem be represented graphically? Can an analysis model be created?

Plan the solution:
• Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, features, and behavior that are required?
• Has a similar problem been solved? If so, are solutions readily apparent for the sub-problems?
• Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

Carry out the plan:
• Does the solution confirm to the plan? IS source code traceable to the design model?
• Is each component part of the solution probably correct? Have the design and code been received, or better, has correctness proof been applied to the algorithm?

Examine the result:
• Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented?
• Does the solution produce results that confirm to the data? Functions, features and behavior that are required? Has the software been validated against all stakeholder requirements?

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 software engineering practice. They are important for that reason.

David Hooker has proposed seven core principles that focus on software engineering practice as a whole. They are reproduced below.

The First Principle: The Reason It All Exists
A software system exists for one reason: to value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting 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, it often takes a lot of thought and works over multiple iterations to simplify. The pay-off is software that is more maintainable and less error-prone.

Alexander Pop (1688-1744): “There is certain majesty in simplicity which is far above all the quaintness of wit.”

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 [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…

Compromising the architectural vision of a software system weakens and will eventually break even a well-designed the 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, others 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 otherwise 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 you writ, and that makes them a user of your code. Making their job easier adds value to the system.

The fifth principles: Be Open to the future
A system with a long lifetime has more value. In today’s computing environments, where specifications change on a moment’s notice and hardware platforms are obsolete after just a few months, software lifetimes are typically measured in months instead of years, however , true “ industrial- strength” software systems must endure far longer. To do this successfully, these systems must be ready to adapt to these and other changes. Systems that do this successfully are those that have been designed this way from the start. Never design yourself into a corner. Always ask “what if”, and prepare for all possible answers by creating systems that solve the general problem, not just the specific on. Author’s note: This advice can be dangerous if it is taken to extremes. Designing for the “general problem” sometimes requires performance compromises and can require more project effort. This could very possibly lead to the reuse of an entire system.

The Sixth Principle: plan Ahead for Reuse
Reuse saves time and effort. Author’s not: Although this is true for those who reuse the software on future projects, reuse can be expensive for those who must design and build reusable components. Studies indicate that designing and building reusable components can cost between 25to 200 percent more than targeted software. In some cases, the cost difference cannot be justified. Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and design has been proclaimed as a major benefit of using object-oriented technologies. However, the return on this investment is not automatic. To leverage the reuse possibilities that object-oriented [or conventional] programming provides, requires forethought and planning. There are many techniques to realize reuse at every level of the system development process. Those at the detailed design and code level are well known and documented. New literature is addressing the reuse of design in the form of software patterns. However, this just part of the battle. Communicating opportunities for ruse to others in the organization is paramount. How can you reuse something that, you don’t know, exists? Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated.

The Seventh Principle: 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. You also gain knowledge about how to do it right again. If you do think about something and still do it wrong, it becomes valuable experience. A side effect of thinking is learning to recognize when you don’t know something, at which point you can research the answer. When clear thought has gone into a system, value comes out. Applying the first Six Principles requires intense thought, for which the potential rewards are enormous.

If every software engineer and every software tam simply followed hooker’s seven principles, many of the difficulties we experience in building complex computer based systems would be eliminated.

COMMUNICATION PRACTICES


Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication (also called requirements elicitation) activity. A customer has a problem that may be amenable to a computer- based solution. A developer responds to the customer’s request for help. Communication has begun. But the road from communication to understanding is often full of potholes.

Effective communication (among technical peers, with the customer and other stakeholders, and with project managers) is among the most challenging activities that confront software engineer. In this context, we discuss communication principles that apply equally to all forms of communication that occur within a software project.

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. Never become contentions in your words or actions 9 e.g., rolling your eyes or shaking your head) as a person is talking.

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. If you have responsibility for conducting a meeting, prepare an agenda in advance of the meeting.

Principle #3: Someone should facilitate the activity.
Every communication meeting should have a leader (facilitator) to keep the conversation moving in a productive direction: (2) to mediate any conflict that does occur; (3) to ensure that other principles are followed.

Principle #4: Face–to-face communication is best.
But it usually works better when some other representation of the relevant information is present. For example, a participant may create a drawing or a “strawman” document that serves as a focus for discussion.

Mark Twain: “shortest road to most perplexities,”
plain questions and plain answers make the shortest road to most perplexities.”

Principle #5: Take notes and documentation decisions:
Things have a way of falling into the cracks. Someone participating in the communication should serves to build trust among team members and creates a common goal for the team.

Principle #6: Stay focused, modularize your discussion.
The more the people involved in any communication, the more likely that discussion will bounce from one topic to the next. The facilitator should keep the conversation modular, leaving one topic to the next. The facilitator should keep the conversation modular, leaving one topic only after it has been resolved (however, see principle #9).

Principle #7: If something is unclear, draw a picture.
Verbal communication goes only so far. A sketch or drawing can often provide clarity when words fail to do the job.

Principle #8: (a) Once you agree to something, move on; (b) If you can’t agree to something, move on; (c) If a feature or function is unclear and cannot be clarified at the moment move on. Communication, like any software engineering activity, takes time. Rather than iterating endlessly, the people who participate should recognize that many topics require discussion (see principle #2) and that “moving on” is sometimes the best way to achieve communication agility.

Principle #9: Negotiation is not a contest or a game. It works best when both parties win.
There are many instances in which the software engineer and the customer must negotiate functions and features, priorities, and delivery dates. If the team has collaborated well, all parties have a common goal. Therefore, negotiation will demand compromise from all parties.

Generic task set for Communication

1. Identify primary customer and other stakeholders.

2. Meet with primary customer to address “context free questions” that define.
• Business need and business values.
• End-users’ characteristics / needs.
• Required user- visible outputs.
• Business constraints.

3. Develop a one- page written statement of project scope that is subject to revision.

4. Review statement of scope with stakeholders and amend as required.

5. Collaborate with customer/end- users to define:
• Resulting outputs and inputs.
• Important software features, functions, and behavior.
• Customer-defined business risks.

6. Develop a brief written description (e.g., a set of lists) of scenarios, output/ inputs, features/ functions and risks.

7. Iterate with customer- defined priorities to each user scenario, feature, function, and behavior.

8. Assign customer- defined priorities to each user scenario, feature, function, and behavior.

9. Review all information gathered during the communication activity with the customer and other stakeholder and armed as required.

10. Prepare for planning activity.

The Different Between Customers and End-users

Software engineers communicate with many different stakeholders, but customers and end-users have the most significant impact on the technical work that follows. In some cases the customer and the end-user are one and the same, but for many projects, the customer and the end-user different people, working for different managers in different business organizations.

A customer is the person or group who: (1) originally requested the software to be built; (2) defines overall business objectives for the software; (3) provides basic product requirements; and (4) coordinates funding for the project. In a product or system business, the customer is often the marketing department. In an IT environment, the customer might be a business component or department.

And end-user is the person or group who: (1) will actually use software that is built to achieve some business purpose, and (2) will define operational details of the software so that the business purpose can be achieved.

PLANNING PRACTICES


The communication activity helps a software team to define its overall goals and objectives (subject, of course, to change as time passes). However, understanding these goals and objectives is not the same as defining a plan for getting there. The planning activity encompasses a set of management and technical practices that enable the software tam to define a road map as it travels towards its strategic goal and technical objectives.

Dwight D. Eisenhower: “In preparing for battle I have always found that plants are useless, but planning is indispensable.”

There are many different planning philosophies. Some people are “minimalists, “arguing that change often obviates the need for a detailed plan. Others are “traditionalists,” arguing that the plan provides an effective road map, and the more detail it has, the less likely the team will become lost. Still others are “agilists,” arguing that quick “planning game” may be necessary, but that the road map will emerge as “real work” on the software begins.

What to do? On many projects, over planning is time consuming and fruitless (too many things change), but under planning is a recipe for chaos. Like most things in life, planning should be conducted in moderation, enough to provide useful guidance for the team- no more, no less.

Regardless of the rigor with which planning is conducted, the following principles always apply.

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.

Principle #2: Involve the customer in planning activity. The customer defines priorities and establishes the project constraints.

Principle #3: Recognize that planning is iterative. As work begins, it is very likely that things will change. As a consequence, the plan must be adjusted to accommodate these changes. In addition, iterative and incremental process models dictate re-planning based on feedback received from users.

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.

Principle #5: Consider risk as you define the plan. If the team has defined risks that have high impact and high probability, contingency planning is necessary.

Principle #6: Be realistic. People don’t work 100 percent every day. Noise always enters into any human communication. Omission and ambiguity are facts of life. Change will occur. Even the best software engineers make mistakes. These and other realities should be considered as a project plan is established.

Principle #7: Adjust granularity as you define the plan. Granularity refers to the level of detail that is introduced as a project plan is developed. A “fine granularity” plan provides significant work detail that is planned over relatively short time increments.

Principle #8: Define how you intend to ensure quality. The plan should identify how the software team intends to ensure quality. If formal technical reviews are to be conducted, they should be scheduled.

Principle #9: Describe how you intend to accommodate change. Even the best planning can be obviated by uncontrolled change. The software team should identify how changes are to be accommodated as software engineering work proceeds.

Principle #10: Track the plan frequently and make adjustments are required. Software project falls behind schedule one day at a time. Therefore, it makes sense to track progress on a daily basis, looking for a problem areas and situation in which scheduled work does not confirm to actual work conducted. When slippage is encountered, the plan is adjusted accordingly.

Why is the system being developed? All parties should assess the validity of business reasons for the software work. Stated in another way, does the business purpose justify the expenditure of people, time, and money?

What will be done? Identify the functionality to be built, and by implication, the task required to get the job done.

When will it be accomplished? Establish a workflow and timeline for key project tasks and identify the milestones required by the customer.

Who is responsible for a function? The role and responsibility of each member of the software tam must be defined.

Where they are organizationally located? Not all roles and responsibilities reside within the software tam itself. The customer, users, and other stakeholders also have responsibilities.

How will the job be done technically and managerially? Once product scope is established, a management and technical strategy for the project must be defined.

How much of each resource is needed? The answer to this question is derived by developing estimates based on answers to earlier questions.

The answers to the above questions are important regardless of the size of complexity of a software project. But how does the planning process begin?

Tom De Marco: “we think that software developers are missing a vital truth: most organizations don’t know what they do. They think they know, but they don’t know.”

Generic task set for Planning:

1. Reevaluate project scope.
2. Assess risks.
3. Develop and/or refine user scenarios.
4. Extract functions and features from the scenarios.
5. Define technical functions and features that enable software infrastructure.
6. Group functions and features (scenarios) by customer priority.
7. Create a coarse granularity project plan.
• Define the number of projected software increments.
• Establish an overall project schedule.
• Establish projected delivery dates for each increment.
8. Create a fine granularity plan for the current iteration.
• Define work tasks for each functional feature.
• Estimate effort for each work task.
• Assign responsibility for each work task.
• Define work products to be produced.
• Identify quality assurance methods to be used.
• Describe methods for managing change.
9. Track progress regularly.
• Not progress areas(e.g., schedule slippage).
• Make adjustments as required.

MODELING PRACTICE


The models are created to gain better understanding of actual entity to be built. When the entity is a physical thing, we can build a model that is identical in form of shape but smaller in scale. However, when the entity is software, our model must take a different form. It must be capable of representing the information that software transforms, the architecture and functions that enable the transformation to occur, the features that user’s desire, and the behavior of the system as the transformation is taking place.

Two classes of models are crated: Analysis models and design models. Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain. Design models represent characteristics of the software that help practitioners to construct it effectively.

Analysis Modeling Principles


A large number of analysis modeling methods have been developed. Each analysis methods has unique point of view. However, all analysis methods are related by a set of operational principles.

Principle #1: The information domain of a problem must be represented and understood. The information domain compasses the data that flow into the system and the data stores that collect and organize persistent data objects.

Principle #2: The functions that the software performs must be defined. Software functions provide direct benefit to visible end-user. Some functions transform data that flow into the system; in other cases, functions effect some level of control over internal software processing or external system elements.

Principle #3: The behavior of the software must be represented. The behavior of computer software is driven by its interaction with the external environment. Input provided by end-users, control data provided by an external system, or monitoring data collected over a network all cause the software to behave in a specific way.

Principle #4: The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered fashion. Analysis modeling is the first step in software engineering problem solving. It allows the practitioner to understand the problem better and establishes a basis for the solution (design). Complex problems are difficult to solve in their entirety. For this reason, we use a divide and conquer strategy. A large, complex problem is divided into sub-problems until each sub- problem is relatively easy to understand. This concept is called partitioning, and it is a key strategy in analysis modeling.

Principle #5: The analysis task should move from essential information toward implementation detail. Analysis modeling begins by describing the problem from the end-user’s perspective. The “essence” of a problem is described without any consideration of how a solution will be implemented.

Design Modeling Principles


The design model created for software provides a variety of different views of system. There is no shortage of methods for deriving various elements of a software design. Some methods are data-driven, allowing the data structure to dictate the program architecture and the resultant processing component. Others are pattern-driven, using information about the problem domain (the analysis model) to develop architectural styles and processing patterns- a set of design principles that can be applied regardless of the method that is used.

Principle #1: Design should be traceable to the analysis model. The analysis model describes the information domain of the problem, uses 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 realize analysis classes.

Principle #2: Always consider the architecture of the system to be built. Software architecture is the skeleton of the system to be built. It affects interfaces, data structures, program control flow behavior, the manner in which testing can be conducted and the maintainability of resultant system.

Principle #3: Design of data is as important as design of processing functions. Data design is an essential element of architectural design. The manner in which data objects are realized within the design cannot be left to chance. A well-structured data design helps to simplify program flow, makes design and implementation of software components easier, and makes overall processing more efficient.

Principle #4: Interfaces (both internal and external) must be designed with care. The manner in which data flow between the components of a system has much to do with processing efficiency, error propagation, and design simplicity, A well designed interface integration easier and assists the tester in validating components functions.

Principle #5: User interface design should be tuned the needs of the end-user. However, in every case, it should be stress free and easy to use. The user interface is the visible manifestation of the software. A poor interface design often leads to the perception that the software is “bad”.

Principle #6: Components should be functionally independent. Functional independence is a measure of the “single- mindedness” of a software component. The functionally that is delivered by a component should be cohesive- that is, it should focus on one and only on function or sub-function.

Principle #7: Components should be loosely coupled to one another and to the external environment. Coupling is achieved in many ways-via component inter-face, by messaging and through global data. As the level of coupling increases, the likelihood of error propagation also increases and the overall maintainability of the software decreases. Therefore, component coupling should be kept as low as is reasonably possible.

Principle #8: Design representation(model) should be easily understandable. The purpose of design is to communicate information to practitioners who will generate code, to those who will test the software, and others who may maintain the software in the future. If the design is difficult to understand, it will not serve as an effective communication medium.

Principle #9: The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity. Like most of the creative activities, design occurs iteratively. The first iteration works to refine the design and correct errors, but later iterations should strive to make the design as simple as is possible.

CONSTRUCTION PRACTICE


The construction activity encompasses a set of coding and testing task that lead operational software that is ready for delivery to the customer or end-user. In modern software engineering work, coding may be: (1) the direct creation of programming language source code; (2) the automatic generation of source code using an intermediate design-like representation of the component to be built; (3) the automatic generation of executable code using a fourth generation programming language.

Coding Principle and Concepts


The principles and concepts that guide the coding task are closely aligned programming style, programming languages, and programming methods. However, there are a number of fundamental principles that can be stated:

Preparation principles: Before you write one line of code, be sure you:
1. Understand the problem you’re trying to solve.
2. Understand basic design principles and concepts.
3. Pick a programming language that meets the needs of the software to the hilt and the environment in which it will operate.
4. Select a programming environment that provides tools that will make your work easier.
5. Create a set of unit tests that will be applied once the component you code is completed.

Coding principles: As you begin writing code, be sure you:
1. Constraint your algorithm by following structured programming practice.
2. Select data structure that will meet the needs of the design.
3. Understand the software architecture and create interfaces that are consistent.
4. Keep conditional statement as simple as possible.
5. Create nested loops in a way that makes them easily testable.
6. Select meaningful variable names and follow other local coding standards.
7. Write code that is self-documenting.
8. Create a visual layout that aids understanding.

Validation principles: After you’ve completed your first coding pass, be sure you:
1. Build architectural infrastructure,
Review the architectural design.
Code and test the components that enable architectural infrastructure.
Acquire reusable architectural patterns.
Test the infrastructure to ensure interface integrity.

2. Build a software component.
Review the component- level design.
Create a set of unit tests for the component.
Code components data structures and interface.
Code internal algorithms and related processing functions.
Review code as it is written.
Look for correctness.
Ensure that coding standards have been maintained.
Ensure that the cod is self- documenting.

3. Unit test the components.
Conduct all unit tests.
Correct errors uncovered.
Reapply unit tests.

4. Integrate completed components into the architectural infrastructure.

Testing Principles:

In a classic book on software testing, Glen Myers states a number of rules that can serve well as testing objectives:

• Testing in a process of executing with the intent of finding an error.
• A good test case is one that has a high probability of finding as as-yet undiscovered error.
• A successful test is one that uncovers an as- yet –undiscovered error.

These objectives imply a dramatic change in viewpoint for some software developers. They move counts to the commonly held view that a successful test is one in which no errors are found. Our objective is to design tests that systematically uncover different classes of errors and to do with a minimum amount of time and effort. These errors can be corrected subsequently.

Davis suggests a set of testing principles that have been adapted for use in this book:

Principle #1: All tests should be traceable to customer requirements. The objective of software testing is to uncover errors. It follows that thee most server defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements/goals.

Principle #2: Tests should be planned long before testing begins. Test planning can began as soon as the analysis model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.

Principle #3: The pare to principle applies to software testing. Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them.

Principle #4: Testing should begin “in the small” and progress toward testing “in the large”. The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find error in integrated clusters of components and ultimately in the entire system.

Principle #5: Exhaustive testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component- level design have been exercised.

Deployment


The deployment activity encompasses three actions delivery, support, and feedback. Because modern software process models are evolutionary in nature, deployment happens not once, but a number of times as software moves towards completion. Each delivery cycle provides the customer and end-users with an operational software increment that provides usable functions and features. The delivery of a software increment represents an important milestone for any software project. A number of key principles should be followed as the team prepares to deliver an increment:

Principle #1: Customer expectations for the software must be managed. The customer expects more than the team has promised to deliver and disappointment occurs immediately. This results in feedback that is not productive and which ruins team morale.

Principle #2: A complete delivery package should be assembled and tested. A CD_ ROM or other media containing all executable software, support data files, support document, and other relevant information must be assembled and thoroughly beta- tested with actual users.

Principle #3: A support regime must be established before the software is delivered. An end-user expects responsiveness and accurate information when a question or problem arises. Support should be planned, support material should be prepared, and appropriate record keeping mechanism should be established so that the software team can conduct a categorical assessment of the kinds of support requested required.

Principle #4. Appropriate instructional materials must be provided to end-users. The software team delivers more than the software itself. Appropriate training aids should be developed, trouble-shooting guidelines should be provided and a “what’s- different about- this-software-increment” description should be published.

Principle #5: Buggy software should be fixed first, delivered later. Under time pressure, some software organizations deliver low-quality increments with a warning to the customer that bugs “will be fixed in the next release”. This is a mistake. There’s a saying in the software business: “Customer will forget you delivered a high- quality product a few days late, but they will never the problems that a low-quality product caused them. The software reminds them everyday.”

Summary
1. The various principles that are discussed in this chapter are the guidelines for a better software engineering practices.

2. If every software engineering and software team follows the Hooker’s seven principles, then many of the difficulties in building the complex system can be solved.

3. The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels towards its strategic goal and tactical objectives.

4. Coding and testing principles lead to a better construction practice.

5. Delivery, support and feedback are combined to form a deployment activity.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Review Questions
  • 1. Discuss software engineering practice and the various elements involved therein.
  • 2. Explain the seven core principles of software engineering practice.
  • 3. What are different principles involved in communication practices and planning practices?
  • 4. What is modeling practice? Discuss in detail the various models and the principles underlying these modeling practices.
  • 5. Explain the construction practice encompassing coding and testing tasks. Discuss the various coding concepts and principles.
  • 6. Discuss the deployment activity in the software field enunciating the various principles involved there under.
Copyright © 2015 Mbaexamnotes.com         Home | Contact | Projects | Jobs

Related Topics
Software Engineering Practices and Software Modeling Practices Keywords
  • Software Engineering Practices and Software Modeling Practices Notes

  • Software Engineering Practices and Software Modeling Practices Programs

  • Software Engineering Practices and Software Modeling Practices Syllabus

  • Software Engineering Practices and Software Modeling Practices Sample Questions

  • Software Engineering Practices and Software Modeling Practices Subjects

  • EMBA Software Engineering Practices and Software Modeling Practices Subjects

  • Software Engineering Practices and Software Modeling Practices Study Material

  • BBA Software Engineering Practices and Software Modeling Practices Study Material