Software project portfolio page is under good developing progress. After a week of effort, most HTML issues in project browser pages are solved.
The portfolio measure definition XML has been added. Now user can use XML file to customize measure definitions in portfolio page. When new telemetry chart is available, user can just add it into the portfolio measure definition XML file and the portfolio page will be ready to use it. As the system is designed for easy configure, the work is quite straight forward to use a XML approach to replace the previous code-based one. The default setting remains the same. So if user don't create the setting file, he will not notice any difference.
I will implement the persisting the user's last configuration settings this week.
Monday, September 29, 2008
Wednesday, September 24, 2008
A week passes fast
After parameter list is added to portfolio configuration panel, portfolio's setting becomes more similar to telemetry. Thus, at last, we change all portfolio page's setting to match that in telemetry page. Time interval in configuration panel has been replaced by start date and end date in input panel. The granularity is moved to input panel as well. And the order of input elements in input panel of both portfolio and telemetry has been modified so that the layout become more consistent over pages.
Before, I was anxious to give user the capacity to select any start/end date in portfolio page. Because I want to create an alternative mechanism that can emphasize the week granularity and its purpose of up-to-date state analysis. But I now realize that, even in stock portfolio system, where most attention is focus on current and future price, provides function to view historical data. Giving user more control power over the system will not harm the initial purpose of the system. Furthermore, users may discover usage that we never think of.
When arranging elements in input panel, I got a chance to look into the panels' layout in the page, and accidentally figure out how to control the layout. Now the pages are more compact and nice.
After added the date selections to portfolio page, the SimDate scenario of portfolio can be put in any time period as I wish. So SimDate is changed.
Before, I was anxious to give user the capacity to select any start/end date in portfolio page. Because I want to create an alternative mechanism that can emphasize the week granularity and its purpose of up-to-date state analysis. But I now realize that, even in stock portfolio system, where most attention is focus on current and future price, provides function to view historical data. Giving user more control power over the system will not harm the initial purpose of the system. Furthermore, users may discover usage that we never think of.
When arranging elements in input panel, I got a chance to look into the panels' layout in the page, and accidentally figure out how to control the layout. Now the pages are more compact and nice.
After added the date selections to portfolio page, the SimDate scenario of portfolio can be put in any time period as I wish. So SimDate is changed.
Tuesday, September 16, 2008
Weekly progress report 0915
The parameter list in portfolio configuration panel is finish! The layout may still need to change, but the functionality is complete. I finally choose to use the well constructed methods in telemetry session to get the parameter definition list. The parameter definition will be needed when showing the configuration panel and when verifying parameters before retrieve data for detail panel. Therefore, if the definition is retrieved every time when it is needed, the reaction of the page will be slow down, especially when open the configuration panel. While there already a map of telemetry definitions, which contain the parameter definitions, managed in telemetry session, it is easier to just use it rather than manage another map of instances in portfolio sessions. But telemetry page and portfolio page are designed to be separated, is it better to keep the class in each page separated? However, there are too many connection between telemetry and portfolio page, both logically and physically, e.g. charts in portfolio has links to the associated telemetry pages. So it should be acceptable to connection the session between them.
After this critical implementation, it is much easier to finish the delayed portfolio simulation data. Before, I got trouble in constructing useful coverage data using the existed methods in SimData, because the granularity of the constructed coverage data is "line" and the default in parameter definition is "method", which is used for portfolio page. There is no reasonable way to change parameters in portfolio page before, so if I insist to do it before adding the parameter configuration, I will have to add some dirty code such as if (measure.name == "Coverage") {...}. I am glad that I don't have to worry about it any more.
For the literature review, I started last week, but did not do well so far. I only finish one article in the week. That article took me over 5 hours to finish. I really need to find more time for it and improve my reading speed.
After this critical implementation, it is much easier to finish the delayed portfolio simulation data. Before, I got trouble in constructing useful coverage data using the existed methods in SimData, because the granularity of the constructed coverage data is "line" and the default in parameter definition is "method", which is used for portfolio page. There is no reasonable way to change parameters in portfolio page before, so if I insist to do it before adding the parameter configuration, I will have to add some dirty code such as if (measure.name == "Coverage") {...}. I am glad that I don't have to worry about it any more.
For the literature review, I started last week, but did not do well so far. I only finish one article in the week. That article took me over 5 hours to finish. I really need to find more time for it and improve my reading speed.
Thursday, September 11, 2008
Literatures Review: Development governance for software management
The article: Development governance for software management
Summary:
Governance is an interesting concept that is different from management. Governance is the act of exerting management control to guide development practices to compliance, while management normally consist of overseeing inward personnel and operations and a set of outward-facing responsibilities: planning, budgeting and forecasting etc.
To measure that to governance, the article use the term key performance indicator(KPI). The two KPIs mainly discuss about are volatility KPI and volume KPI -- both are process KPIs. The volatility is good to measure and predict development processes. Monitoring the volume will help to forecast project to adjust resource distribution; assure quality; and measure the efficacy of a software design in programming aspect. It also talked a little bit about work-product KPIs such as coding guidelines and complexity.
Relevance to my research:
In Hackystat, volatility is measured as Churn and volume is measured as FileMetric. Hackystat also provides other measures like coupling, coverage, build, test, commits and code issue. They are now equal. But from the enlightening from the article, I realize they should be group into two: process measures and work-product measures. The formers show the performance of the develop team while laters show the quality of the product. The understanding of these two groups are different thus research to them should be somehow differentiated.
Process measures will include:
Work-product measures will include:
An important idea from the article is that all these measures have to be monitor over time to give significant meaning. Even when talking about volume, what make sense is the change of the volume over time -- LOC increase relatively slow indicates efficacy design and bloated code usually brings negative impacts. The idea of looking at these measures is to look into their trend, in order to predict the processes. This match our idea in Project Portfolio. We show not only the current state of each measure, but also the historical trends. And we estimate projects performance from their analysis trend as well.
Summary:
Governance is an interesting concept that is different from management. Governance is the act of exerting management control to guide development practices to compliance, while management normally consist of overseeing inward personnel and operations and a set of outward-facing responsibilities: planning, budgeting and forecasting etc.
To measure that to governance, the article use the term key performance indicator(KPI). The two KPIs mainly discuss about are volatility KPI and volume KPI -- both are process KPIs. The volatility is good to measure and predict development processes. Monitoring the volume will help to forecast project to adjust resource distribution; assure quality; and measure the efficacy of a software design in programming aspect. It also talked a little bit about work-product KPIs such as coding guidelines and complexity.
Relevance to my research:
In Hackystat, volatility is measured as Churn and volume is measured as FileMetric. Hackystat also provides other measures like coupling, coverage, build, test, commits and code issue. They are now equal. But from the enlightening from the article, I realize they should be group into two: process measures and work-product measures. The formers show the performance of the develop team while laters show the quality of the product. The understanding of these two groups are different thus research to them should be somehow differentiated.
Process measures will include:
Work-product measures will include:
An important idea from the article is that all these measures have to be monitor over time to give significant meaning. Even when talking about volume, what make sense is the change of the volume over time -- LOC increase relatively slow indicates efficacy design and bloated code usually brings negative impacts. The idea of looking at these measures is to look into their trend, in order to predict the processes. This match our idea in Project Portfolio. We show not only the current state of each measure, but also the historical trends. And we estimate projects performance from their analysis trend as well.
Monday, September 8, 2008
Weekly progress report
Last week I have mainly worked on project portfolio. Validators has been added to configuration panel to ensure that higher threshold is always higher that lower threshold.
Now I am working on a "simpleportfolio" simulated dataset in SimData for the use of Tutorial Guided Tour of Portfolio analysis. Hopefully will finish today or tomorrow.
Future improvements for portfolio will include:
Now I am working on a "simpleportfolio" simulated dataset in SimData for the use of Tutorial Guided Tour of Portfolio analysis. Hopefully will finish today or tomorrow.
Future improvements for portfolio will include:
- telemetry parameters for each measure
- new measures from telemetry: dev time, build & unit test
- show member of each project -- may not necessary to be an analysis, just show it near the project name, or in active members measure if available.
- new analysis: active members -- inactive members are those have significantly less dev time than others, others are all active members.
Monday, September 1, 2008
Plan of thesis resreach
This fall I am starting the research on my master thesis.
The topic of the thesis is about how to compare projects with the metrics provided by Hackystat.
In large companies, it is possible to have hundreds of projects at a same time. The abilities to understand and compare this large amount of project is a great challenges and opportunities for both project managers and developers. Managers will want to figure out how those projects are doing as well as how the develop groups are doing. Developers will like to find similar projects or groups for further communication on technique, tools, etc.
Utilizing Hackystat's auto-collected data of software development procedure, we build a Software Project Portfolio Management page on Project Browser. It demonstrates projects using a set of software procedure metrics with both present value and historical chart. These values and charts are colored according to the thresholds and trends. Users are able to quickly scan this portfolio and get fast understand from colors and narrow down their interest to several projects. Then they can have further investigation into those projects.
However, understanding of such a software project portfolio is still far from sufficient. We don't know if all metrics we using are useful, or there may be some interesting metrics we should introduce to the system. How to color the charts and value is also uncertain. So we give the system the capacity to adapt different situation and need. Users can define the value thresholds for each metrics, determine if the higher value means better, and select the color for good, bad and so so values and trends. In the future, users may even define more than 3 color spaces for value and more colors for more different trends.
To study this system, we are planning first evaluate it in classroom. We will:
The topic of the thesis is about how to compare projects with the metrics provided by Hackystat.
In large companies, it is possible to have hundreds of projects at a same time. The abilities to understand and compare this large amount of project is a great challenges and opportunities for both project managers and developers. Managers will want to figure out how those projects are doing as well as how the develop groups are doing. Developers will like to find similar projects or groups for further communication on technique, tools, etc.
Utilizing Hackystat's auto-collected data of software development procedure, we build a Software Project Portfolio Management page on Project Browser. It demonstrates projects using a set of software procedure metrics with both present value and historical chart. These values and charts are colored according to the thresholds and trends. Users are able to quickly scan this portfolio and get fast understand from colors and narrow down their interest to several projects. Then they can have further investigation into those projects.
However, understanding of such a software project portfolio is still far from sufficient. We don't know if all metrics we using are useful, or there may be some interesting metrics we should introduce to the system. How to color the charts and value is also uncertain. So we give the system the capacity to adapt different situation and need. Users can define the value thresholds for each metrics, determine if the higher value means better, and select the color for good, bad and so so values and trends. In the future, users may even define more than 3 color spaces for value and more colors for more different trends.
To study this system, we are planning first evaluate it in classroom. We will:
- let the students in ICS413 to use this system during their course program development
- do several survey about their opinion of the system and their preferred customization
- track down their usage of the system
Subscribe to:
Posts (Atom)
