07.10.2014 09:09 |
Software Development
Classical CIP processes fall short and take into account the future increasing proportion of ‘software production’ or too little development. (Image: Phoenix Contact)
boundary condition of the future project Industry 4.0 is the digitization of the production landscape. And with the advent of the Internet and modern technologies in the production, this will succeed. The production halls are transformed into self-thinking systems in which the product to be manufactured decide on which line it is produced.
The upcoming changes affect not only the users and the manufacturers. They are the ones who so plan their products, components and machines, must develop and manufacture according to industry-4.0-compliant methods that they can be integrated into the appropriately designed facilities. Such products are intelligent, communicative and based on software, which has an increasingly large share of the new developments. This provides the seller with some challenges. The reason: Traditional considerations of production costs ignore the value of the software. Rather, the pricing of a product is usually based on the production and material costs. The increasing financial burden for the creation of software is now most common in the overheads. In this calculation model, the software does not contribute to the value of the product. In this point, a rethinking must take place, as innovation – also in software -their price
Software development is not measured or controlled
The productivity models have to change.. So far, the production process is the heart of the general process chain. It is designed to be as optimal as possible, which is why the production process in most companies precisely controlled, logged and continuously improved (CIP). In other words, the productivity is measured. In software-based products with a disproportionate share of the software to the value of the traditional focus of CIP is no longer enough. After installing the software packages on the product can be optimized barely. In addition, the manufacturing step ‘software download’ does not match the actual production process, software development ‘. Is of concern, moreover, that the innovation of many steps more and more products are in the software, while the hardware remains unchanged. Other product variants will emerge from new software versions. Consequently, results for a different software process chain.
The innovation potential of manufactured products thus lies in the software, which does not focus CIP measurements on the creation process. It is assumed that many manufacturers do not measure today their software development – and thus can not control. For example, a control lacking actual information about the quantity, quality, personnel costs or appointments – parameters, such as they are, of course, for each production. Without such actual data but can be defined and checked no target values
With all creativity -. Software development is measurable
Simplified process model of the software life cycle: innovation and product variants arise more and more in the software development process. (Image: Phoenix Contact)
The aspect of lack of knowledge raises many questions. The focus is on the discussion of whether it is possible at all make an analogy between software development and classic production process. Finally, the development of software is generally regarded as a creative process. Creativity can simply measure?
A look at the development phases of a software version helps: The process is divided into planning, specification, implementation, testing and release. Regardless of an agile or traditional development approach these stages occur always and for each version of the product.
The products used in industrial environments have a long life. If this is for instance ten years, and each year three software versions are created, resulting in total 30 versions. Each version has a defined functions, described by specific requirements. The implementation of the requirements does not require a creative process in the sense of technological innovation, because: Central conditions such as operating systems, processors, or architecture models used do not change in the rule. Rather, developers and testers need to constantly think about how can implement the requirements within the limits of the above conditions with the least possible effort quickly and flawlessly and test. Factors such as number, cost, time required and error rate are measured.
The software research thoroughly deals with the productivity in software development. There is extensive literature on methods and empirical studies. However, a uniform system not recognizable. The existing norms and standards also do not help, because there are no relevant rules. Models such as CMMI (Capability Maturity Model Integration) or Spice (Software Process Improvement and Capability Determination) require from a certain level of maturity, the measurement of software development. However, they do not prescribe specific methods. Therefore, the manufacturer of the many approaches to design and implement for their purposes most appropriate approach.
Devil’s Square supports the productivity determination
Devil’s Square by Harry Sneed: If you want the development process to improve, should increase efficiency of a parameter not held the detriment of another. (Image: Phoenix Contact)
In the configuration of the concepts the devil square of Harry Sneed provides orientation. The four factors to be considered productivity form the vertices of the square. The square within the square, indicating the achievable productivity, can be enlarged by increasing the quantity and quality while reducing development time and costs. A unilateral change does not necessarily lead to higher productivity, for example, if the quality is improved at the expense of development time.
The use of this model is to define the next, as the mentioned factors are measured. The costs result primarily of personnel expenses, which is why an accurate reporting system for measurement is necessary. This seemingly simple task can be challenging, such as when appropriate reporting systems and lack a precise mapping of activities into a version is not possible in practice already. The detection of the development time increases the complexity further. Discussion material already has the question of when the work will start on a version: with the capture of the requirements by the product managers or only with the specification, implementation and testing by the development? Beginning and end of activities therefore need to be clearly defined.
The measurement of objective quality numbers proves to be more difficult. They aim to objectify the discussion in terms of quality and demonstrate improvements. This against the background because individual problems are often all the software in question. Here, fault management systems have been established. The analysis of the dataset, however, hears frequently when looking at the number. We recommend further analysis at the time of acquisition, for example, before and after the release, as well as the introduction of a classification. The ISO / IEC 25010 provides for is a possible basis. However complicated question arises from the quantity of the software. Possible approaches are to measure the lines of code churn (changes in the code) or Function Point Methods in the environment. Each of these methods provides accurate figures on the amount of software. Code-based metrics can therefore comparatively easy to implement, whereas functional methods require trained experts.
six-step sequence forms the basis for the evaluation
A good way software quality: error classification according to the ISO / IEC 25010 -Qualitätsmodell. (Image: Phoenix Contact)
All productivity factors can be measured and each other instead into consideration – for example in the form of Points per Hour . Granted, the implementation is, however, difficult. The following steps offer themselves as meaningful sequence:
Introduction of an Application Lifecycle Management system in which the center all the effort, time, error, source codes, specifications and tests are recorded
- Draft a suitable metrics-model
- implementation of a measurement method
- tracking of actual values
- formulation of desired values
- continuous review of reaching the target values.
The growing value of 4.0 according to industry manufactured products through software. This requires a productive software development by the manufacturers. You need to assess their capacity to improve this measure continuously. At the beginning of such a process can not answer all questions. This should not prevent you to take up the challenge to manufacturers. For each measurement is better than none.
SPS IPC Drives 2014
Hall 9, Booth 310
No comments:
Post a Comment