As noted earlier, software failure is always associated to the product itself, not to the extent why the software failed. To observe a fail-safe and error-free operation, early detection of waste is needed to remove the same quickly.
Waste elimination is initiated in conformance with software quality control result-oriented and quality assurance process-oriented. In this context, it promotes process- centric software development which oversees compliance to requirement specification on each process or stage of the development.
The pre-industry developers revealed the following which constitutes the Cause and Effect- Level 1. The Cause and Effect Diagram-Level 1. From the Figure 3 representation, waste is considered as effect of 6Ms, and based on the results of content analyses; transcripts from the focus group discussion, field notes and observations, there have been several causes of wastes in software development.
The respondents were asked to elicit and elaborate their contention to the following; 5. Management includes the strategic down to the operational level employees who were contend to the system users during the unit testing, modular testing and system testing. During the requirements gathering, these company representatives were asked in the User Specific Requirements, Functional Requirements, Non-Functional Requirements, Data Analysis and others.
During the documentation, design and development, the developers blocked a schedule to present the system to meet User Characteristics and other functional value of the system. More importantly, the end-users are included amongst the Project Stakeholder.
Once streamlined, inefficient processes will be removed and replaced with tried and true approach and will be integrated into the function of the system.
Also, being a pre-industry developer, their constraints are on the System Analysis and Design course processes as well. These tests include unit test, module tests, integration tests, systems tests, and Business Acceptance Testing. Because of several stakeholder involved, several changes are employed which includes the emergency changes to system, major and minor changes, standard and normal changes. During the requirements gathering, they will conduct Focus Group Discussion, Semi-Structured Interview and other means of getting necessary documents which will be used as input to their documentation and system design and development.
Also, associated to materials are the program codes, modules, and other functions. To close more projects with impressive team records, each of the 6Ms must be visited to eliminate foregoing causes of wastes below. This section presents details on the root cause analysis of software development wastes. Figure 4. The Cause and Effect Diagram-Level 2. With this therefore, reworks after the deployment and maintenance period is not a subject of their responsibility, and they have had considered it waste, should there be system improvement after the period it is regarded as another milestone of the project.
The developers communicate in the technical language they are into while the clients have their common understanding on the lay-mans and or business language on their workplace culture. You may have skilled team on Java, JSP, JavaScript and others, however your client just need a system which requires skills in Visual Basic, your team is a waste also.
In the concept of Project Management, cases like this can be resolved by having multiple projects or accounts handled by a team so that idle time is eliminated. This makes emergency changes on the system interface, function and the entire processes.
Also, for some developers, there were identified codes which do not add value and function to the system. Should there be changes to processes and functions, documentation should be put in place and document control must be maintained for versions of changes and updates.
Participants noted, that in every changes or process modification, system complexity arises. Wastes such as undeployed codes, undocumented processes, and untested codes are attributed to fall under this category.
Layout, functions, design of system which is pleasing on the Managers perspective if not appealing and not accepted by the client is a waste. The Business Acceptance Test supersedes other test.
Use case, Test case needs to be done on additional features; features which actually not required by the user, non-value adding features, and tests for every non-value adding features are considered wastes.
Therefore, developers must consider the significant- important, and the necessary-sufficient conditions. For the developers, technology is the machine use to do their related tasks in the project, the integrated development environment, and the infrastructure of the workplace. Obsolete technology is a waste as well; surely because if it is more costly to maintain existing technology than acquiring new ones, it is impractical to a business or organization.
The granularity is always put on top and processing mechanism. In this study, developers have noted wastes attributed as Material. Information is considered as variable in a system. Good information system provides generation of new knowledge, reusability, and scalability and among others. Developers noted that excessive revisions on the documentation, processes, and extra features not specify by the clients requirements are amongst wastes in software development.
It has been noted that Lean principles in software development summarizes seven principles which includes; a eliminate waste, b amplify learning, c decide as late as possible, d deliver as fast as possible, e empower the team, f build integrity in, and g see the whole [20].
As previously noted on the introductory, implementation of Lean Software Development can eliminate wastes at an early stage. In lean thinking, the concept of waste is high hurdle. If a component is sitting on a shelf gathering dust, that is waste. If a development cycle has collected requirements in a book gathering dust that is waste.
If the developers code more features that are immediately needed, that is waste. The ideal is to find out what a customer wants, and then make or develop it and deliver exactly what they want, virtually immediately [20]. Additional features, codes are therefore waste.
Lean philosophy regards everything not value- adding to the customer as waste [21], and in order to eliminate waste it should be recognized first. A value stream mapping technique can be used to identify wastes. Waste to SD may include; a unnecessary code and functionality, b delay in the software development process, c unclear and vague requirements, d insufficient testing leading to avoidable process repetition , e bureaucracy, and f slow internal communication [21].
Software development is a continuous learning process with the additional challenge of development teams and end product sizes… the accumulation of defects should be prevented by running tests as soon as the code is written [22]. The best approach to improving a software development environment is to amplify learning since SD is best conceived of as a similar learning process with added challenge that development teams are large and the results are far more complex [20].
Development practices that provide for late decision making are effective in domains that involve uncertainty, because they provide option-based approach [20]. It's an important tenet for self-managing teams, encouraging them to avoid detailed discussions of items not currently under development or nearby on the planning horizon [24]. The software should be designed in such a way so that it can deliver as much increments as possible.
Any increment is working software and opens up the feedback loop for any potential problems [26]. Mary and Tom noted that The shorter the cycles are, the more can be learned. The causes are broken out into major cause categories. The causes you identify will be placed in the appropriate cause categories as you build the diagram. The right side of the diagram lists the effect. The effect is written as the problem statement for which you are trying to identify the causes.
The diagram looks like the skeleton of a fish, which is where the fishbone name comes from. The first step of any problem solving activity is to define the problem. You want to make sure that you define the problem correctly and that everyone agrees on the problem statement.
After the problem statement has been placed on the diagram, draw the major cause categories on the left hand side and connect them to the "backbone" of the fishbone chart. You can start with those categories or use a different set that is more applicable for your problem. There isn't a perfect set or specified number of categories. Use what makes sense for your problem. Brainstorming the causes of the problem is where most of the effort in creating your Ishikawa diagram takes place.
Some people prefer to generate a list of causes before the previous steps in order to allow ideas to flow without being constrained by the major cause categories. However, sometimes the major cause categories can be used as catalysts to generate ideas. This is especially helpful when the flow of ideas starts to slow down. If all the other ingredients are gathered then the developer can technically do what is expected of him. But will he do it? Will the resulting code be stellar or botched? That depends on its motivation.
This one covers both expertise and method because one can compensate for the other. Granted, he will take more time to complete the task than an expert. Tools also have an impact on software quality. Building software on top of a solid framework reduces the amount of code to write and therefore the likelihood of introducing mistakes.
Static analysis tools can catch potential issues as code is written and further improve the quality of the code.
0コメント