Lean software development two case studies

And we are reducing that time line by removing the non-value-added wastes. Build it fast: Dramatically reduce the lead time from customer need to delivered solution. Build the thing right: Guarantee quality and speed with automated testing, integration and deployment.

Learn through feedback: Evolve the product design based on early and frequent end-to-end feedback. Understand and deliver real value to real customers. A software development team working with a single customer proxy has one view of the customer interest, and often that view is not informed by technical experience or feedback from downstream processes such as operations.

A product team focused on solving real customer problems will continually integrate the knowledge of diverse team members, both upstream and downstream, to make sure the customer perspective is truly understood and effectively addressed.

Dramatically reduce the lead time from customer need to delivered solution. A focus on flow efficiency is the secret ingredient of lean software development. How long does it take for a team to deploy into production a single small change that solves a customer problem? Typically it can take weeks or months — even when the actual work involved consumes only an hour. Because subtle dependencies among various areas of the code make it probable that a small change will break other areas of the code; therefore it is necessary to deploy large batches of code as a package after extensive usually manual testing.

In many ways the decade of was dedicated to finding ways to break dependencies, automate the provisioning and testing processes, and thus allow rapid independent deployment of small batches of code.

Guarantee quality and speed with automated testing, integration and deployment. It was exciting to watch the expansion of test-driven development and continuous integration during the decade of First these two critical practices were applied at the team level — developers wrote unit tests which were actually technical specifications and integrated them immediately into their branch of the code.

Test-driven development expanded to writing executable product specifications in an incremental manner, which moved testers to the front of the process. This proved more difficult than automated unit testing, and precipitated a shift toward testing modules and their interactions rather than end-to-end testing. Once the product behavior could be tested automatically, code could be integrated into the overall system much more frequently during the development process — preferably daily — so software engineers could get rapid feedback on their work.

Next the operations people got involved and automated the provisioning of environments for development, testing, and deployment.

Finally teams which now included operations could automate the entire specification, development, test, and deployment processes — creating an automated deployment pipeline. There was initial fear that more rapid deployment would cause more frequent failure, but exactly the opposite happened.

Automated testing and frequent deployment of small changes meant that risk was limited. When errors did occur, detection and recovery was much faster and easier, and the team became a lot better at it. Far from increasing risk, it is now known that deploying code frequently in small batches is best way to reduce risk and increase the stability of large complex code bases.

Evolve the product design based on early and frequent end-to-end feedback. To cap these remarkable advancements, once product teams could deploy multiple times per day they began to close the loop with customers.

When these four principles guided software development in product organizations, significant business-wide benefits were achieved. However, IT departments found it difficult to adopt the principles because they required changes that lay beyond span of control of most IT organizations. Lean Software Development: - saw the publication of two significant books about lean software development. Just at the time when two week iterations began to feel slow, Kanban gave teams a way to increase flow efficiency while providing situational awareness across the value stream.

Over the next few years, the ideas in these books became mainstream and the limitations of agile software development software-only perspective and iteration-based delivery were gradually expanded to include a wider part of the value stream and a more rapid flow.

A grassroots movement called DevOps worked to make automated provision-code-build-test-deployment pipelines practical. Cloud computing arrived, providing easy and automated provisioning of environments. Cloud elements virtual machines, containers , services storage, analysis, etc. Improved testing techniques simulations, contract assertions have made error-free deployments the norm.

They create full stack teams that are expected to understand the consumer problem, deal effectively with tough engineering issues, try multiple solutions until the data shows which one works best, and maintain responsibility for improving the solution over time. Large companies with legacy systems have begun to take notice, but they struggle with moving from where they are to the world of thriving internet companies.

Lean principles are a big help for organizations that want to move from old development techniques to modern software approaches. In fact, focusing on flow efficiency is an excellent way for an organization to discover the most effective path to a modern technology stack and development approach.

Low flow efficiencies are caused by friction — in the form of batching, queueing, handovers, delayed discovery of defects, as well as misunderstanding of consumer problems and changes in those problems during long resolution times. The servi e returns the a tual time to the plug-in. The PUT olle ts the overage data. The automation tool plug-in sends the ASK signal to the servi e. The servi e sends the ask signal to the PUT. The PUT sends ba k the overage data to the servi e.

The servi e sends ba k the overage data and the a tual time to the automation tool plug-in. The stored data are: exe ution time, tra e length, overage value, lists of overed and not overed methods.

These steps are repeated during the whole test suite exe ution. The plug-in is ontrolled from the test ases. It indi ates the beginning and the end of a test ases to the servi e layer appli ation.

The servi e replies to these signals by sending the valuable data ba k. When the measurement lient indi ates the start of a test ase by sending the NEWTC message to the servi e , the servi e replies with the urrent time whi h is stored by the lient. At the end of a test ase when the ASK signal is sent by the lient , the servi e replies with the urrent time and the olle ted overage information of the methods. When the overage data is re eived, the measurement lient omputes the exe ution time, tra e length the number of method alls , and the list of overed and not overed methods' IDs.

As an alternative lient, we implemented a simple standalone java appli a- tion that is able to onne t to the measurement servi e and this way it repla es the RT-Exe utor plug-in.

This lient is able to visualize the ode overage in- formation online, and is useful during the manual testing a tivities e. Test exe ution framework with overage measurement 3. In the pilot proje t, we implemented some of the possible appli ations. A prioritized list of test ases an be ut at some points resulting in a kind of sele tion. Code overage data an be used for test ase sele tion and prioritization. Exe uting the sele ted test ases an only redu e the time required for regression test exe ution while the failure dete tion apability of the suite is not redu ed.

It an prioritize the tests either in the des ending or the as ending order of the length of their tra es. There are two possible reasons for a ode part not being overed by any test ase exe utions. It an also happen that the not overed ode annot be exe uted by any test ases, whi h means that it is a dead ode.

In the latter ase, the ode an be dropped from the odebase. In our pilot implementation, automati test ase generation is not imple- mented. We simply al ulate the lists of methods overed and not overed during the tests.

These lists an be used by the testers and the developers to examine the methods in question and generate new test ases to over the methods, or to simply eliminate the methods from the ode. Some of them an simply be re orded when the artifa t is reated, some of them must be determined later.

If a requirement-method pair is assigned with high orrelation, we an assume that the required fun tionality is imple- mented in the method. This information an be used to asses the number of methods to be hanged if the parti ular requirement hanges. A media-settings appli ation was sele ted for testing our methodology and implementation. We did not ondu t detailed experimentation in this topi , but we did test the tool.

Then, we assigned these fun tionalities to 15 omplex bla k-box test ases of the media appli ations and exe uted the test ases with overage measurement. The tra eability tool om- puted orrelations between the 12 fun tionalities and methods, and was able to separate the methods relevant in implementing a fun tionality from the not relevant methods.

Although there were more solu- tions allowing the measure of the ode overage of Android appli ations on the developers' omputers, no ommon methods were known to us that performed overage measurement on the devi es. We also reported the implementation of this methodology on a digital Set-Top-Box running Android. There are many improvement possibilities of this work. This would allow us to extra t instru tion and bran h level over- ages that would result in more reliable tests.

We are also thinking of improving the instrumentation in order to build dynami all trees for further use. The ur- rent implementation simple overage measurement does not need to deal with timing, threads and ex eption handling, both of whi h are ne essary for building the more detailed all trees.

It would also be interesting to help the integration of this overage measurement in ommonly used ontinuous integration and test exe ution tools.

We are also examining the utilization possibilities of the resulting overage data. For example, tra eability information between ode and the visible graph- i al elements ould be established, and this information might help to partially automate olle ting data for usability tests and to establish usability models.

We are planning to ondu t resear hes in these topi s. Referen es 1. Google: Android homepage. Kukolj, S. Gotlieb, A. In: Pro eedings of the 1st international workshop on Random testing.

Costa, J. Biswas, S. Hazelwood, K. In: Pro eedings of the international onferen e on Compilers, ar hite ture and synthesis for embedded systems. Marek, L. In Jhala, R. Volume of Le ture Notes in Computer S ien e. Chawla, A. Seesing, A. Slife, D. Chiba, Shigeru: Javassist homepage. Google: apktool homepage.

Google: dex2jar. Google Android Developers: Building and running an android appli ation. Bornstein, D. Developers: JSON. Yoo, S. Technical debt management requires means to identify, track, and resolve technical debt in the various software project artifacts. There are several approaches for identifying technical debt from the software implementation but they all have their shortcomings in maintaining this information. This paper presents a case study that explores the role of dependency propagation in the accumulation of technical debt for a soft- ware implementation.

A clear relation between the two is identified in addition to some differentiating characteristics. We conclude that formal- ization of this relation can lead to solutions for the maintenance problem. As such, we use this case study to improve the propagation method im- plemented in our DebtFlag tool. Keywords: technical debt, technical debt propagation modeling, soft- ware implementation assessment, refactoring 1 Introduction Technical debt is a metaphor that describes how various trade-offs in design de- cisions affect the future development of the software project.

Similarly to its financial counterpart, technical debt - for example through reuse in software implemen- tations - accumulates interest over a principal until it has been paid back in full. Inability to manage the projects technical debt results to increased interest payments in the form of additional resources being consumed when implement- ing new requirements and ultimately to exceeding development resources and premature ending of the project. There are various software project artifacts, such as process, testing, architecture, implementation, and documentation, that are prone to the afore- mentioned decisions and thus to hosting technical debt.

As these fields differ from each other to a large degree, techniques for managing technical debt are separate for each of them. For the software implementation artifact, we can divide the technical debt identification techniques into automated [3] and manual approaches [4]. What is problematic is that the information produced by either of these approaches is only applicable to the assessed implementation version: automated approaches can produce results for all implementation versions, but they only highlight modules that are in violation when compared against a static model, leaving out information regarding module relations and links to previous implementation versions.

Manual approaches on the other hand do provide some information re- garding the history of a certain technical debt occurrence, but update frequencies to this information make these approaches only capable for tracking and manag- ing technical debt on higher levels. These observations have lead us to conclude that if the relation between software implementation updates and increases in technical debt could be made explicit, we could extend the applicability of tech- nical debt information, produced for a certain implementation version, to future versions.

This would greatly increase the efficiency of technical debt information production for software implementations. In this paper we present a case study that explores the aforementioned op- portunity. Basing onto related research we make an assumption that dependency propagation is largely responsible for the accumulation of technical debt in the software implementation and that by better understanding this relationship we can increase the efficiency of technical debt information production and main- tenance for this area.

We focus on exploring this relationship by deriving two objectives for this case study: to identify technical debt and its structure in the studied system as well as to establish the role of dependency propagation in the formation of this structure.

The presented study is part of a research into establishing if a tool-assisted approach can be introduced for software projects in order to efficiently identify, track, and resolve technical debt in developed implementations. The results of this case study will be used to further develop the DebtFlag-tool [5] see Figure 1 and its propagation model for technical debt.

The tool is used to identify technical debt instances from the implementation and to merge them into entities allowing management at both the implementation and project levels. DebtFlag code highlighting and content-assist cues in the Eclipse IDE [5] amongst others, in the works of Brown et al. A general consensus between these definitions is that technical debt bases on a principal on top of which some interest is paid.

The principal corresponds to the size and amount of unfinished tasks that emerge as design decisions make trade-offs be- tween development driving aspects.

Principal is paid back by correctly finishing these tasks. Interest is increased by making more solutions depend onto areas where there are unfinished tasks. When creating these solutions, if additional work is required due to nonoptimality of these areas, this constitutes as paying interest. Seaman et al. The occurrence probability takes into account that not all technical debt affects the project: for example if a part of the software implementation is never re-used, the probability of this part hindering further implementation updates is zero.

Management of technical debt can be either implicit - like in many agile software practices, where reviews are made during and in between iterations to ensure that the sub-products meet the organizations definition of done - or explicit - like employing a variation of the Technical Debt Management Frame- work [4], [8]. In either case, the success of technical debt management is largely, if not solely, dependent onto the availability of technical debt information [7].

To clarify, in the previous paragraph, a software implementation component refers to an entity that is defined by the used programming paradigm and tech- nique and is capable of forming dependencies.

The target system of this case study is implemented using the Java programming language. Here, like in many object oriented languages, direct references and inheritances create dependencies to public interfaces formed out of variables and methods [9]. In order to maintain the technical debt information produced either by means of automatic or manual identification, there needs to exist a model explaining how technical debt propagates in the software implementation.

A theory on the propagation of technical debt in ecosystems by McGregor et al. Additionally, certain implementation technique and paradigm specific characteristics need to be taken into account when identifying possible propaga- tion routes for technical debt. Especially interfaces which can hide partitions of technical debt or decouple dependents from refactorizations. Software implementation technical debt is paid back through refactoring the software product.

Fowler et al. In the following, we use this definition to identify which software components where affected by technical debt. In this, they hypothesize that technical debt has the ability to aggregate within elements of the software implementation and provide two concurrent mechanisms for it. In respect of this, they note that technical debt may diminish as a result of increased implementation layer nesting.

For a software implementation this can mean for example that the implementation of a new element does not necessar- ily increase the technical debt quota but deficiencies in the documentation still result into more consumed resources. Research is scarce in relating technical debt accumulation with the mechan- ics of software dependency propagation. Thus, we refer to research on software evolution and change impact analysis to gain insight into dependency propa- gation and its characteristics.

It is also concluded that the use of more specialized information in the definition of the propagation paths, results into a more specific and accurate impact set. In Bianchi et al. Robillard [14] presents an algorithm for pro- viding an interest ranking for directly dependent change candidates. The ranking of elements is based onto specificity and reinforcement, where the former rules that structural neighbors that have few structural dependencies are more likely to be interesting because their relation to an element of interest is more unique and the latter that structural neighbors that are part of a cluster that contains many elements already in the set of interest are more likely to be interesting because.

It is a collaborative education platform that is being developed and researched at the University of Turku [15,16]. The system specializes in enabling the creation and to being host to various exercises with education enhancing features such as rich visualizations and immediate feedback [17, 18]. To date, the system has foregone 8 years of development, comprises circa k physical lines of code, serves over 1. During its eight years of development ViLLE has gone over several smaller and two larger revamps.

The first major revamp unified the platform into a single Java Applet and introduced automatically assessable exercises. Conversion to a Java Applet allowed the system to be run from the TRAKLA server which made the system accessible through the Internet and enabled its integration into distance teaching. The second major revamp enhanced this further: in order to reduce requirements to the end user to a bare minimum the system was converted into a SaaS Software as a Service by way of utilizing the Vaadin framework [19].

The old legacy exercise system was found to be too rigid for this purpose and it was decided that this part of the system was to be refactored. The authors have taken part in this process and it has also been the focus of a thesis [20]. The interactive student view of a ViLLE-coding-exercise [16] The thesis has documented the entire refactorization project that is used in the case study presented in this paper.

Approaching the research problem we have divided it into two objectives. The first objective is to iden- tify and produce a structured documentation for technical debt in the target implementation.

The second objective is to understand the role of dependency propagation in the formation of this structure. Fulfilling the first objective requires that we are first able to distinguish between modifications made to develop the implementation and modifications made to refactor the implementation.

After identifying modifications that be- long to the latter - and count as paying of technical debt, further information is required to identify relations between the modifications.

Revealing these rela- tions allows us to arrange the individual modifications to form a structure that indicates how technical debt has accumulated in the implementation.

Dependencies are formed between elements of the implementation. As each identified modification operates on a set of implementation elements we can utilize the dependency formation rules to identify all elements that are dependent onto this set. Comparing the revealed dependencies to the connections in the technical debt accumulation structure is used in this case study to examine the role of dependency propagation in the accumulation of technical debt for the software implementation.

This case selection is made to expand on earlier research de- scribed in [20]. We consult this research to establish what parts of the system were targeted in the refactorization, what are the tools and practices used for the refactorization, what are the motivations as well as the requirements for the refactorization and finally access to the version control system which is queried for information regarding the conduction of this refactorization.

The ViLLE system is a web-application that is implemented using the Vaadin web-application framework. The used development language is Java. At the time of the refactoring the running configuration of the ViLLE system was comprised out of k physical lines of code organized into a hierarchy of 26 Java packages encompassing a total of Java classes.

The thesis [20] documented that the motivation for the refactorization was that the development team perceived the exercise system to be too rigid to accommodate efficient development in the future.

Further analysis in [20] pin- pointed this problem to four Java classes. These core system classes were respon- sible for the execution, modification, storing and retrieving, as well as modeling of interactive exercises in ViLLE. For each of these [20] documented a set of problems as well as a set of reparative actions, which were used as the starting point for the refactorization.

The refactorization used a well defined refactorization process - adapted from The Rhythm of Refactoring by Fowler et al. Applying this five step process first called for identi- fying change points.

In this case, all references to specific exercises. The next step of finding test points consisted from identifying change routes and under- standing how the system could be shielded from unintended changes by way of constraining these routes with tests.

The third step called for breaking depen- dencies in order to get the tests in place. The end result of this was a set of unit tests adhering to the JUnit framework.

The last, fifth, step was to make changes and refactor. An example of a singular refactoring here was the removal of specific exercise information from the constructor of the exercise executor. Development towards refactoring the system was done independent from the main development line.

In practice, a separate version control branch was used. Further, due to the nature of this project the branch in question could only contain commits that corresponded to meeting the requirements of the refac- torization.

From the point-of-view of this case study, we interpreted this as all modifications observable from this version control branch as constituting to pay- ing of technical debt and thus relevant data to the study in question. We constrained this data set to the branch in the version control system identified in Section 4. As this constriction limited the data set to only containing modifications that corresponded to refactorizations, we proceeded to building the structured representation for technical debt accumulation for this implementation see Section 4.

In Section 2. Successfully paying off technical debt for the implementation im- plies that individual refactorizations are able to nullify the adaptations as well as to remove the root cause. In this case the root cause was confined within four Java classes Section 4. Each of these classes were responsible for implement- ing an independent and distinctive functionality in the system.

As the structured representation for technical debt accumulation was to reflect how inabilities in implementing system functionalities had affected the system, four root nodes were chosen. Each root node consisted out of a set of modifications correspond- ing to all refactorizations made to repair the functionality of - and to remove the root cause from - one aforementioned class.

Having identified the root nodes and their modification sets, we continued to study the remaining modifications. Links between modifications were deter- mined as cause-effect-relations: a link existed between modifications if success- ful completion of the cause-one required a successful completion of the effect- one.

The two step process was repeated until all modifications were associated with the structure for technical debt accumulation. To facilitate the fulfillment of the second objective, we related information about the propagation of dependencies to the structured representation for tech- nical debt accumulation.

As the system in question is implemented using the Java language the object-oriented paradigm as well as the Java technology can be consulted for information about the propagation of dependencies in the im- plementation. This set was then queried to find out if it contained elements being targets of mod- ifications linked with the modification used to spawn the set. The results were then associated with the structure for technical debt accumulation in order to clearly indicate the role of dependency propagation in its formation.

Analysis of the resulting structures is done to fulfill the second objective. The research problem was divided into two objectives: determining and provid- ing a structured representation for the accumulation of technical debt in the implementation as well as relating dependency propagation information to this structure in order to understand its role in the formation of the structure.

The data used in the analysis of this case study is an interval of version control revi- sions encompassing an entire refactorization undertaking for a software system. Analyzing revisions of the ViLLE system, we found that the refactorization consisted out of individual modifications or refactorizations which affected a total of 71 Java classes.

Amongst these were the four Java classes encompassing what [20] had identified as the root cause. Observing which modifications realized the removal of the root cause in these four classes lead to the formation of four modification sets that served as the root nodes for our structured representation for technical debt accumulation. According to the case study design see Section 4. Identification of cause- effect-relations for all modifications also indicated that a modification could only be associated with a single substructure.

The resulting technical debt accumulation structure was then associated with information regarding the propagation of dependencies. This corresponded to identifying the target elements for all modifications, identifying sets of elements that were dependent on the target elements, searching for possible relations between element dependencies and modification links and finally relating this information to the technical debt accumulation structure.

The same visual aids apply for all presented TDPTs. Nodes represent modi- fications Section 5. Arrows indicate cause-effect-relations between modifications. If a dependency exists between the target elements of modifications of a cause-effect-relationship, then the node for the effect-modification is modeled as an ellipse.

If not, the node is modeled as a rectangle. If the modification type is addition of new implementation el- ements, then the node is colored green light shade. Else, if the modification type is removal of implementation elements, then the node is colored red dark shade.

Finally, the number inside each node is the sum of dependencies to target elements of the modifications. The Technical Debt Propagation Tree having the modifications made to the exercise execution implementation as its root node 6 10 3 1 1 4 3 3 1 1 1 1 1 1 1 1 1 1 Fig.

The Technical Debt Propagation Tree having the modifications made to the exercise modification implementation as its root node 71 44 50 55 1 1 1 12 2 1 1 3 3 1 2 1 1 1 1 1 1 3 1 2 2 1 4 8 18 3 4 2 3 2 2 Fig. The Technical Debt Propagation Tree having the modifications made to the exercise data modeling implementation as its root node 5.

First, modifications to implementation elements with a large number of incoming dependencies seem to invoke an increased number of further modifica- tions. This however is not consistent as the number of incoming dependencies deviates from the number of invoked modifications, which is evident for example by observing the TDPT for data modeling Figure 6 : at the second tier of the tree where the number of incoming dependencies greatly exceeds the number of invoked modifications in five occasions - more than ten incoming dependencies while number of invoked modifications is five for one case and zero for others.

Second, examining the cause-effect-relations forming the edges of our TDPTs, in all but two cases there exists a dependency between underlying implementa- tion elements for an observed cause-effect-relationship between modifications. In the second non-dependency case between the root and a second tier node in TDPT for data modeling in Figure 6 similar motivation could be observed.

Exercise type declarations were separated here from the generic exercise data model and placed into their own containing class. Hence, it seemed that in al- most all cases dependency propagation was the evident cause for technical debt accumulation.

Third, examining the depths of the TDPTs we can observe the following. In the case of TDPTs for storing and retrieval as well as data modeling the tree depth is three, while for TDPTs for execution and modification the tree depth is four see Figures 4, 6, 3, and 5 respectively.

Further, for all leaf modifications the number of dependencies incoming to their target elements is rather low - under ten. Except for the few cases mentioned in the previous paragraph. Fourth, an observation made from the evident differences in the tree struc- tures. In the case studied system modifying a component that is responsible for providing a data model in the implementation see TDPT for data modeling in Figure 6 seemed to invoke a series of modifications that could be described as shallow but wide.

While, modifications responsible for implementing specific features of the system seemed to invoke a series of modifications that were more narrow and focused than the former see TDPTs for execution, modifying, and storing and retrieval in Figures 3, 5, and 4 respectively. This seems to indicate that for refactored-to-be elements of the implementation, their role in the system could be used to postulate the course of the refactorization undertaking in this part of the system. The research problem was divided into two objectives and an approach was derived to fulfill them.

Applying this approach to case study data resulted into the successful formation of four Technical Debt Propagation Trees. Analysis of these trees lead to the following observations. The number of incoming dependencies correlates with the number of propa- gation paths for technical debt with the exception of a small number of events which does not adhere to this. Secondly, dependency propagation can be seen to drive the accumulation of technical debt in this software implementation, ex- cept for two cases where this can not be observed.

Thirdly, examination of the TDPTs supports what has been earlier hypothesized about technical debt di- minishing due to dependency propagation. Finally, as an additional observation, the role of a system component could be used to explain how technical debt had propagated in the system. Concluding onto these observations: it is evident that dependency propaga- tion plays a significant role in the accumulation of technical debt for a software implementation.

If differences between the propagation paths for technical debt and implementation dependencies can be taken into account, this information could be automatically generated for indicated sources of technical debt providing a mean to forecast the state of the software implementation as well as a tool to estimating the size and urgency of reparative efforts. Finally, these conclusions indicate that the approach derived for this case study is vi- able for examining the role of dependency propagation in the accumulation of technical debt.

In this case study all observed modifications were accepted as paying off technical debt. This acceptance criteria was based firstly on to the provided definition of a refactorization in Section 2. It can be argued that the used acceptance criteria was too loose, and the resulting TDPTs were over popu- lated. The results of this case study required that we identified a causal relation be- tween the propagation of dependencies and the accumulation of technical debt.

Sec- tion 4 explained the processes used for determining both cause-effect-relations between modifications as well as the propagation of dependencies between im- plementation elements.

Here, the latter is determined based on static rules and confirmed in the ability for the program to function. While most information in the contexts - for example close chronological ordering and linkage between affected implemen- tation areas - lead to a strong conclusion, the possibility of making a wrong decision can not be excluded.

However, issue-free and successful association of all modifications indicates that uncertainty played a small role in this step. Firstly, we intend to employ the approach derived and used in this case study for additional data sets. We expect this to provide more details on the intrin- sics of technical debt accumulation in software implementations in addition to further examining the role of dependency propagation in this process. Further, the results of this and following analyses will be used to build and assess the propagation model used by the DebtFlag-tool [5].

As the tool relies on the ability to maintain technical debt notions through this model, explicitly presenting the differences in the propagation paths of technical debt and depen- dencies between implementation elements will allow for further enhancements.

As such, our ongoing research is focused on assessing and evaluating possible models to identify viable solutions. A strong candidate is the link structure al- gorithm PageRank by Page et al.

Initial analyses with the data provided in this paper has yielded promising results especially in accommodating the diminishment characteristic of technical debt. Cunningham, W. Volume Ozkaya, I. Notes 36 5 September 33—35 3. Izurieta, C. Seaman, C. Advances in Computers 82 25—46 5. Holvitie, J. Brown, N. Guo, Y. It made engineers spend too much time on building complex, monolithic systems packed with unneeded features. It restrained them from adapting the software to the ever-changing environment and client requirements.

As a result, lean engineers came up with the concept of MVP minimum viable product and overall opposite philosophy: build quickly, include little functionality and launch a product to the market as fast as possible. Then, study the reaction. Such approach allows to enhance a piece of software incrementally, based on the feedback collected from real customers, and ditch everything that is of no value.

Lean software development is a system aimed at empowering team members, rather than controlling them. It goes beyond establishing basic human courtesy; it instills trust within each project. Engineers are granted freedom to make important development decisions, based on knowledge they receive whilst writing code and their own judgment. Such approach contributes a lot to a faster application of changes to software that are needed to reflect the changes in the environment, and it keeps your developers motivated.

Setting up a collaborative atmosphere, however, and keeping the perfect balance of control within the project is hard. According to Mary and Tom Poppedniecks , sub-optimizing is one of those unfortunate tendencies that, though being unproductive, still occurs often in traditional IT departments. Managers choose to break each issue into multiple constituent parts, which they then have their teams fix separately, without optimizing entire systems.

Lean software development opposes that and stands for focusing on value stream as a whole. At Perfectial, for instance, we find people that are best suitable for each specific project and organize them into complete, standalone teams. Therefore, look for expertise when hiring a team to build your application; professionals, who are committed to a continuous improvement, and qualified enough to embody the core values of Lean methodology — delivering as much value, in the shortest amount of time and in a most efficient way possible.

Want to learn more about lean software development and how your company can benefit from it? Due to the development of IT technologies, modern education experienced a major metamorphosis.

Digital content is replacing textbooks and manuals…. A proper diagnosis…. Every website serves the purpose of attracting visitors to your service or product and eventually, turning them into customers.

Please leave this field empty. All publications. What is Lean Software Development? Overall, there are 7 principles to Lean software development , each aiming to quicken delivery and bring higher value to end-user: Eliminating Waste Building Quality In Amplifying Knowledge Delaying Commitment Delivering Fast Respecting people Optimizing the whole thing To fulfill them, Lean makes use of such tools: Inventory management.

Eliminating Waste Waste reduction, being the first rule in Lean engineering, defines its entire purpose. Unnecessary features and code More tasks in log than can be completed Delays in the engineering process Vague requirements Inefficient communication Issues with quality Unneeded and crippling bureaucracy Data duplications Costs of aforementioned To identify and eliminate waste, regular meetings are held by Project Managers after each short iteration.

Building Quality In Efficient quality management is, too, a guiding principle in lean development methodology, as issues in this area lead to different types of waste. You can change your cookie settings through your browser. Open Advanced Search.

DeepDyve requires Javascript to function. Please enable Javascript on your browser to continue. Lean Software Development: Two Case Studies Lean Software Development: Two Case Studies Middleton, Peter This paper shows how the concepts of lean manufacturing can be successfully transferred from the manufacture of cars and electrical goods to software development. Read Article. Download PDF.

Share Full Text for Free. Web of Science. Let us know here. System error. Please try again! How was the reading experience on this article? The text was blurry Page doesn't load Other:.