Beruflich Dokumente
Kultur Dokumente
A static load is a force, which is gradually applied to a mechanical component or system which does not
change its magnitude or direction with respect to time. Engineering materials are classified into two
groups ductile and brittle materials. A ductile material e.g Al, structural steelsis one which has a relatively
high tensile strain before fracture takes place. On the other hand, a brittle material e.g. cast iron has a
relatively low tensile strain before fracture.
Failure by elastic deflection: In applications like transmission shaft supporting gears, the maximum
force acting on the shaft, without affecting its performance, is limited by the permissible elastic
deflection. Lateral or torsional rigidity is considered as the criterion of design in such cases.
Failure by general yielding: A mechanical component made of ductile material loses its engineering
usefulness due to a large amount of plastic deformation after the yield point stress is reached.
Considerable portion of the component is subjected to plastic deformation, called general yielding
Failure by fracture: Components made of brittle material cease to function satisfactorily because of the
sudden fracture without any plastic deformation.
Nptel pdf///
Design based for life cycle
For many durable goods, there are a variety of other design considerations related to the total product
life cycle. For consumable products, some of these life cycle factors may be of lesser importance. Life
cycle factors that may need to be addressed during product design include:
Testability/Inspectability
Reliability/Availability
Maintainability/Serviceability
Upgradeability
Installability
Human Factors
The relative importance of these factors and their orientation will vary from industry to industry and
product to product. However, there are general design principles for these life cycle requirements that
will be generally applicable to many items. A basic integrated product development concept is the
parallel design of support processes with the design of the product. This parallel design requires early
involvement and early consideration of life cycle factors (as appropriate) in the design process.
However, in many organizations, consideration or design of the support processes is an after-thought
and many of these developmental activities are started after the design of the product is well under way
if not essentially complete.
Test and inspection processes can consume a significant amount of effort and the development or
acquisition of test equipment can require considerable time and expense with some products. Early
involvement of the test engineering or quality assurance functions can lead to design choices that can
minimize the cost of developing or acquiring necessary equipment and the effort to test or inspect the
product at the various stages of production. A starting point is to establish a common understanding
between Engineering, their customers, and other functional departments regarding the requirements
for product qualification, product acceptance after manufacture, and product diagnosis in the field. With
this understanding, a design team can begin to effectively design products and test and inspection
processes in parallel.
Increasingly complex and sophisticated products require capabilities and features to facilitate test and
acceptance of products and diagnosis products if a defect is identified. Specific principles which need to
be understood and applied in the design of products are:
Use of Geometric Dimensioning and Tolerancing (GD&T) to provide unambiguous
representation of design intent
Specification of product parameters and tolerances that are within the natural capabilities of the
manufacturing process (process capability index Cp and Cpk)
Provision of test points, access to test points and connections, and sufficient real estate to
support test points, connections, and built-in test capabilities
Standard connections and interfaces to facilitate use of standard test equipment and connectors
and to reduce effort to setup and connect the product during testing
Built-in test and diagnosis capability to provide self test and self-diagnosis in the factory and in
the field
In addition, test engineering should be involved at an early stage to define test requirements and design
the test approach. This will lead to the design or specification of test equipment that better optimizes
test requirements, production volumes, equipment cost, equipment utilization, and testing effort/cost.
Higher production volumes and standardized test approaches can justify development, acquisition, or
use of automated test equipment. The design and acquisition of test equipment and procedures can be
done in parallel with the design of the product which will reduce leadtime. Design of products to use
standardized equipment can further reduce the costs of test equipment and reduce the leadtime to
acquire, fabricate, and setup test equipment for both qualification testing and product acceptance
testing.
Reliability consideration has tended to be more of an after-thought in the development of many new
products. Many companies’ reliability activities have been performed primarily to satisfy internal
procedures or customer requirements. Where reliability is actively considered in product design, it tends
to be done relatively late in the development process. Some companies focus their efforts on
developing reliability predictions when this effort instead could be better utilized understanding and
mitigating failure modes, thereby.developing improved product reliability. Organizations will go through
repeated (and planned) design/build/test iterations to develop higher reliability products. Overall, this
focus is reactive in nature, and the time pressures to bring a product to market limit the reliability
improvements that might be made.
The orientation toward reliability must be changed and a more proactive approach utilized. Reliability
engineers need to be involved in product design at an early point to identify reliability issues and
concerns and begin assessing reliability implications as the design concept emerges.
Use of computer-aided engineering (CAE) analysis and simulation tools at an early stage in the design
can improve product reliability more inexpensively and in a shorter time than building and testing
physical prototypes. Tools such as finite element analysis, fluid flow, thermal analysis, integrated
reliability prediction models, etc., are becoming more widely used, more user friendly and less
expensive.
Design of Experiments techniques can provide a structured, proactive approach to improving reliability
and robustness as compared to unstructured, reactive design/build/test approaches. Further, these
techniques consider the effect of both product and process parameters on the reliability of the product
and address the effect of interactions between parameters.
Failure Modes and Effects Analysis (FMEA) is analytical technique to identify potential failure modes and
take action to improve reliability. Each potential failure mode in every component in a product is
analyzed to determine potential failure modes, their associated causes or mechanisms, the risks of these
failure modes, and any mitigating controls or actions to reduce the probability or impact of the failure.
Fault Tree Analysis (FTA) is another verification technique. It is a top-down, hierarchical analysis of faults
to identify the various fault mechanisms and their cause. It uses Boolean logic to graphically describe the
cause and effect relationships that result in major failures. The fault or major failure being analyzed is
identified as the “top event.” All of the possible causes of the top event are identified in a tree using
“or” nodes for independent causes and “and” nodes for multiple causes that must exist concurrently for
a failure to occur. FTA is used with many safety critical products. Based on these types of analysis,
designers would take actions to reduce the liklihood of failures or faults thereby improving reliability
and durability.
Accelerated Life Testing (ALT) or Highly Accelerated Life Testing (HALT) are also test approaches to
enhance and demonstrate a product’s reliability and life. Since life testing of the product could take a
long period of time with a long-life product, ALT exposes the product to more extreme environmental
conditions than the operating environment to reduce the amount of time test how the product will
perform when exposed to less extreme conditions (the operating environment) over a longer period of
time (the product’s expected life). ALT is oriented to testing a product to determine the reliability or
durability of a product and to determine the dominant failure modes. HALT is used during development
to find ways that product will fail over its planned life. This is done by exposing the product to even
more extreme environmental conditions until a product fails. The cause of the failure is then determined
and the design is refined to make it more robust with respect to the environmental conditions. In other
words, HALT is focused on testing a product to failure in order to identify its weak points and, thereby,
make it more reliable and robust.
Finally, the company should begin establishing a mechanism to accumulate and apply “lessons learned”
from the past related to reliability problems as well as other producibility and maintainability issues.
These lessons learned can be very useful in avoiding making the same mistakes twice.
Identify modules subject to wear or greater probability of replacement. Design these modules,
assemblies or parts so that they can be easily accessed, removed and replaced.
Design for diagnosibility; use built-in self-test and monitoring capabilities to quickly isolate faults
and problems.
Use common handtools and a minimum number of handtools for disassembly and re-assembly.
Minimize serviceable items by placing the most likely items to fail, wear-out or need
replacement in a small number of modules or assemblies. Design so that they require simple
procedures to replace.
Design for Maintainability guidelines has much in common with Design for Manufacturability guidelines.
In addition, service and support policies and procedures need to be developed, service training
developed and conducted, maintenance manuals written, and spare parts levels established. As these
tasks are done in parallel with the design of the product, it reduces the time to market and will result in
a more satisfied customer when inevitable problems arise with the first delivery of a new product.
We all make mistakes. Such a mistake might be forgetting to turn the lights off before leaving the house,
or unintentionally cutting off another driver on the way to work. Or, as a software developer, it might be
accidentally introducing a defect into the newest software project the team is working on. While defects
are inevitable during development, they can largely be identified, fixed, or prevented entirely long
before they reach a production environment. Throughout this article we’ll explore a few tips for
reducing production defects, which will boost overall software quality, reduce regressive issues, improve
inter-team communication, and increase customer satisfaction. Let’s take a look!
Many businesses and organizations have a strong tendency to view defects in a skewed and unhealthy
light. Defects are inevitable at some point throughout the overall software development life cycle, but
many traditionally-managed organizations view defect and error management as a basically binary
battle to beat back the bugs. There is rarely acknowledgement that defects will crop up, and that
healthy processes to combat their arrival must be planned out and executed. Instead, the ultimatum
from the executives and managers on high can often be summarized thusly: “Attention maggots!
Proceed with elimination of X% of defects. TAKE NO PRISONERS!”
While defects during development are a necessarily evil, the goal shouldn’t be to just eliminate bugs,
but rather to develop practices and procedures that simplify the identification, debugging, and
resolution of defects. Just as importantly, these processes should be implemented early in the
development life cycle, and constantly improved upon. With healthy practices in place, defects can
become something that are no longer considered an inevitability, but are instead a rare surprise, like
seeing a digital unicorn on a distant hill — you didn’t expect it, but you’re glad you spotted it, and have a
desire to investigate it further.
This change in attitude, particularly for well-established organizations that may be accustomed to more
traditional outlooks on defects, may be difficult, but the shift in attitude must be a top down process.
Executives and managers need to alter their perceptions that defects are inevitable (particularly in
production), and instead, view bugs as exceptional. This change in perception will eventually traverse
downward throughout the company, eventually leading to a paradigm shift in the groupthink attitudes
about defects. This will open an avenue toward changes in how the organization handles problems,
which will eventually lead to a dramatic reduction in production defects.
Set aside an adequate block of time on a regular basis (weekly, monthly, quarterly, etc) and meet with
the managers and development leads throughout the team to discuss the detailed software
requirements of the project. This process should identify exactly what requirements are necessary for
the overall application, as well as detailed component- or feature-specific requirements. The major
benefit of this practice is uncovering potential pitfalls and preventing a large portion of unnecessary
defects that may otherwise crop up down the road.
For example, during a software requirements analysis meeting your team may come to the conclusion
that the data layer implementation that was previously planned (like Azure) may not work with a
required third-party component, so the requirements must be changed to another solution (such as
AWS). Failing to identify such an issue early in the development life cycle will often lead to an
assortment of painful issues, and if ignored long enough, could cause a slew of production defects that
could have been easily prevented. Since the vast majority of defects that crop up during an application’s
development are related to failures during software requirement planning — as opposed to actual
coding and implementation issues — it’s critical that this process be taken seriously, and be performed
both early and often.
With a solid plan for establishing sound software requirements laid out, the next habit to get into is to
implement organization-wide code refactoring practices. Refactoring aims to improve and redesign the
structure of already existing code, without modifying its fundamental behavior. Simple examples of
refactoring include fixing improperly names variables or methods, and reducing repeated code down to
a single method or function.
This self-review process on code should also include peer review. Many companies find great success in
pair programming techniques, whereby two individuals sit together during actual code development,
with one developer writing code and the other watching as an observer. While this practice increases
the man-hours required to complete any given line of code studies show that code produced from pair
programming will contain approximately 15% fewer defects than code produced by solo programmers.
The best way to reduce production defects through any form of code review is to ensure the processes
your organization has established are practiced frequently — repetition will create habitual processes
that invariably catch potential problems and existing defects well before they reach the production
environment.
Invariably, some defects will appear at some point in the software development life cycle, so it’s
important that your team takes full advantage of the benefits these provide. Specifically, a defect
presents the opportunity to perform deep analysis on the affected components of the software and
make improvements to all areas that were impacted. How your organization chooses to perform
analysis will be specific to your team and application, but there are a few key principles to keep in mind
when sussing out the root cause of any given defect:
Aim to Improve Quality: Above all else, all the tips and practices laid out in this article are aimed
at improving the quality of the software throughout future iterations and into production
releases. Thus, defect analysis should aim to both prevent defects or, for those that still slip
through the cracks, to detect them as early as possible.
Rely on Expert Team Members: Quality Assurance departments are beneficial and often
necessary for particularly large projects, but don’t neglect the members of your development
team that were involved with actually producing the code or components that caused the
defect. Identifying these members is not to pass down any judgment or shame them, but rather
to empower these individuals to analyze the problem and come up with the most elegant
solution.
Prioritize Systematic Defects: Throughout the typical development life cycle there will tend to
be a handful of defects that are regressive — issues that repeatedly appear again and again, in
spite of the team’s best efforts to squash them. Such systematic defects should be prioritized
during the analysis process and heavily focused on, as doing so will have the biggest impact on
overall defect rates.
The concepts of continuous integration, continuous delivery, continuous deployment, and the like are
not merely buzzwords; they are highly effective practices that can dramatically improve software quality
by taking much of the headache out of iterative releases and deployments.
Continuous integration is the practice of automatically building and testing your application on a regular
basis. The frequency of testing will depend on your business needs, but with the many powerful tools
that are now available this process can occur for every build, or even for every single commit to the
shared repository.
Continuous delivery is less of a practice and more of a concept; the idea that your code base should
always be release-ready. What this means is debatable, but the basic idea in most implementations is
that your application should always be ready for a single-click (or scheduled and automated) full release
into a staging or production environment.
Lastly, continuous deployment is the culmination of these continuous practices and is where the actual
deployment of releases or patches take place and are available for wider use (staging, production, etc).
Some organizations choose to streamline these processes so much that they are deploying new,
updated builds to the production environment on a daily basis.
Automated exception tracking and reporting tools, like Airbrake, ensure that your team is immediately
aware of exceptions the moment they occur. Airbrake’s powerful error monitoring software guarantees
that your team won’t need to worry about losing track of that rare production defect that slips through
the cracks. Airbrake provides real-time error monitoring and automatic exception reporting for all your
development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock
status updates on your application’s health and error rates. No matter what you’re working on, Airbrake
easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to
customize defect parameters, while giving you complete control of the active error filter system, so you
only gather the errors that matter most.
/// pdfs