Architecture
JSF is a Component based UI framework. It is industry endorsed framework governed by JCP
Provides cleaner separation of concerns; uses MVC architecture
Robust event handling architecture. Each JSF component hierarchy is associated with rich set of listeners
JSF has in-built plug-in architecture to support application scalability; any third libraries like Tomahawk (JSF enabled components) shall be easily integrated and extended.
Robust event handling mechanism
All UI components initiate OO web-application development. Thus JSF enabled web applications can leverage on rich-proven OO practices for rapid application development
Usability (Both Application end user and Application developer)
Increased user interface experience with rich client features like data grid, trees, dashboard features, auto-complete, auto-refresh etc
Increased application user productivity with the help of in-built features like asynchronous page rendering, automatic refresh of server data, reduced number of user clicks and auto page submissions
Multiple options to select JSF specification implementation frameworks like Sun RI, Apache My faces, JBoss Rich faces and Exadel’s facelets for application development
Comprehensive JSF tool support from leading industry vendors; such tools includes Eclipse, JDeveloper, IBM RAD, Sun Studio and JBoss Studio
Provides in-built validation framework to validate UI inputs. Significant reduction in development time; moreover validation framework uses latest JSTL enabled expression language
All JSF custom tags are JSTL/EL aware
Scalability
JSF rendering kit provides different rendering techniques to handle requests like WML, XML etc. In other words; it is not limited to HTML only. So JSF enabled application are scalable in nature to address different clients with out changing underlying business/data architecture
Provides seamless integration with Ajax technology. All JSF component tree model are Ajax aware; so any non-Ajax application can leverage on this excellent scalable feature. Again application developer has good support from open source frameworks like Ajax4JSF
Provides pluggable life cycle phase listeners. So JSF based application can be scalable to add in-built listeners against application’s future requirements
JSF is based on standard converters. Custom converters can be easily developed or extended for ever changing requirements
Maintainability
JSF based applications shall be maintained with ease; provides good separation from configuration files, backing beans, form beans etc. Backing beans shall be developed using POJO centric development model. If application leverage on ORM solution like Hibernate; then significant reduction in code; thus better management of the application
Clean separation of roles; Thus better managed application source repository both development and maintenance phase
Custom JSF components like progress bar, drag n drop, file movement etc shall be reused across the application. So there is no redundancy in source code.
30 May, 2008
28 May, 2008
27 May, 2008
Factors to be considered for productvity measurement of agile practices
Abstract
The Agile methodology really lacks its ability to collect the productivity metrics. Agile gives utmost priority to satisfy the customer with the help of frequent deliveries of working software. However there are several factors do exist to capture agile metrics. Following article discusses some of those.
Factors to be considered for productivity measurement
Following section list downs the different factors to be considered to measure the productivity of agile practices, viz., SCRUM, Continuous Integration, Workshops and Dual Monitors. Each factor might applicable to one or more agile practices.
1) Customer satisfaction
It is one of the better ways to measure the productivity of the agile processes or related practices. Each iteration/sprint will end-up with tangible output which is going to perceived or evaluated by the client according to his/her business requirements. So in this process no of customer feedbacks (good as well as not so good), his active participation frequency and delivery satisfaction rate (on the scale of 1-5) etc shall be measured.
Applicability: SCRUM, Continuous integration, Workshops
2) Reduced/Manageable risk
The number of risks envisaged and able to mitigate the risks with successful counter measurements per iteration. Also how team as a whole successfully managed the risk with in iteration with out affecting the delivery. It requires disciplined way to capture such instances during iteration. Best candidate would be Scrum Master.
Applicability: SCRUM
3) Improved quality
Quality differs from context to context. From the SCRUM aspect, it is reduced code review defects, increased design/architectural specific brain storming sessions, reduced build rejections from internal QC/ or client, Increased junior team member participants in design workshops, increase in review efficiency, reduce in number of failed attendees for SCRUM stand-up meeting, etc…
Applicability: SCRUM, Workshops, Continuous Integration
4) On time delivery
On time delivery of working software (with duly tested!) of all story points identified for the iteration. If any delay in delivery; then associated delay can be measured in number of person days / or IEH
Applicability: SCRUM
5) Innovation
The number of innovative ideas/best practices adopted to deliver out of box solution with in iteration. It might be good design strategy, improved code quality, increased automation by using good tools under all stages of SDLC cycle etc. Again it is in process matrix collection mechanism, Scrum Master is the best person to judge such initiatives.
Applicability: SCRUM, Workshops, Continuous Integration
6) No of Reusable components to the organization
How many reusable components are contributed to the organization from the project? Here code is fully tested and moved to client’s production environment. Any such code which does not have any customer obligations shall be moved organization’s reusable component repository. It can be measured across the projects over the period of time. This measurement shall be conducted against iteration or specific period of time.
Applicability: SCRUM, Agile process as a whole
7) Increased knowledge sharing activities
How many times from specific SCRUM team member shared his technical competency with others in the form of presentations, trainings, articles etc. Any such instances shall be captured.
Applicability: SCRUM
8) Team engagement
Team engagement during sprint, shall be calculated in the form of Ideal Engineering Hours (IEH). Also overall team engagement in the form of understanding requirement, design, code, review, testing, training, research etc shall be classified.
Applicability: SCRUM (Backlogs)
9) Burn down charts
Burn down chart is early warning system, which gives product owner how the team is performing to achieve user story points for current iteration. At high level; number of high level warnings occurred during sprint / or across the sprint(s) shall be measured.
Applicability: SCRUM
10) Personal Excellence
Capture information such as how many people with in SCRUM team are being certified for various technological tools/frameworks? How many people participated seminars, training programs? How many team members contributed to open source projects or initiatives? Thus increase in company branding etc...
Applicability: SCRUM
11) Agile maturity
Judge the team maturity with help of schedule over run, effort over run (directly related to matured way of conducting task estimation), what kind of task selection from team member during iteration planning, active participation instances in various workshops, retrospective meetings, stick on to realization of sprint goals, adherence to multiple project checklists etc. Any violations or innovative ideas should be captured as part of sprint.
Applicability: SCRUM
12) Compliance with respect agile principles/or number of tailor made approaches which violates agile principle
Capture any agile principle violations in the form of tailor made requirements; might be influenced by external stakeholder. Also identify number of agile principles being practiced on iteration basis. Derive such matrix at the end of each iteration. In my opinion it is the most important activity shall be considered with high priority.
Applicability: SCRUM, Workshops, Continuous Integration
13) Obstacles cleared per iteration
Capture number of blockers removed per iteration.
Applicability: SCRUM
14) Number of De-scoped functions/tasks over into next iteration
All de-scoped story points of the current sprint
Applicability: SCRUM
15) Number of retrospectives per iteration
How often SCRUM teams adheres to “Inspect and Adapt” principle? Identify number of retrospectives being conducted with in sprint. Also capture what are the types of retrospective meetings are being practiced and related feedback from the team.
Applicability: SCRUM
16) Implementation status of retrospective action items
It is number of outstanding retrospective action items from previous sprints.
Applicability: SCRUM
17) Number of functional tests / iteration or user story
It is a process of capturing number of functional tests developed and applied against user story points per iteration.
Applicability: SCRUM, Continuous Integration
18) Unit tests / iteration
Capture number of unit test cases against code developed per sprint.
Applicability: SCRUM, Continuous Integration
19) Number of builds / iteration
Capture number of successful builds / or broken builds per sprint.
Applicability: SCRUM, Continuous Integration
20) Number of functional defects / iteration
It is number of functional defects found by both internal QC team and client.
Applicability: SCRUM, Continuous Integration
21) Lines of code
It is mainly concentrated on development team productivity on lines of code delivered for the specific period. For example; KLOC/Person day. But most of the agile practicing companies discourage this approach as 50 lines of code with just variable declarations can’t be more productive compare to just 20 lines of code which does important business functionality. In my opinion it is most crud way to measure productivity; shall be discarded.
Applicability: SCRUM, Continuous Integration
22) Function Point
It is originally intended to use for project estimation. It revolves under Input, Output (Report) and data. Again as explained with LOC; one can not depend on FP for measurement for the simple reason, a simple CRUD operation will carry more function point where in most complex business scenario which does not have any output will carry less FP. In my opinion each FP should have weightage and determination of weight-age will ask for definitive discussion.
Applicability: SCRUM
23) Velocity
Sustained development pace of the team is determined by Velocity mechanism. Here it depends on number of story points delivered per iteration. Most of the agile practitioners recommend this approach to determine overall team productivity. Here also some fundamental question arises like “if team of 3 delivers 40 story points where in another team of 10 delivers 50 story points, so which sprint team is more productive?”
Applicability: SCRUM
The Agile methodology really lacks its ability to collect the productivity metrics. Agile gives utmost priority to satisfy the customer with the help of frequent deliveries of working software. However there are several factors do exist to capture agile metrics. Following article discusses some of those.
Factors to be considered for productivity measurement
Following section list downs the different factors to be considered to measure the productivity of agile practices, viz., SCRUM, Continuous Integration, Workshops and Dual Monitors. Each factor might applicable to one or more agile practices.
1) Customer satisfaction
It is one of the better ways to measure the productivity of the agile processes or related practices. Each iteration/sprint will end-up with tangible output which is going to perceived or evaluated by the client according to his/her business requirements. So in this process no of customer feedbacks (good as well as not so good), his active participation frequency and delivery satisfaction rate (on the scale of 1-5) etc shall be measured.
Applicability: SCRUM, Continuous integration, Workshops
2) Reduced/Manageable risk
The number of risks envisaged and able to mitigate the risks with successful counter measurements per iteration. Also how team as a whole successfully managed the risk with in iteration with out affecting the delivery. It requires disciplined way to capture such instances during iteration. Best candidate would be Scrum Master.
Applicability: SCRUM
3) Improved quality
Quality differs from context to context. From the SCRUM aspect, it is reduced code review defects, increased design/architectural specific brain storming sessions, reduced build rejections from internal QC/ or client, Increased junior team member participants in design workshops, increase in review efficiency, reduce in number of failed attendees for SCRUM stand-up meeting, etc…
Applicability: SCRUM, Workshops, Continuous Integration
4) On time delivery
On time delivery of working software (with duly tested!) of all story points identified for the iteration. If any delay in delivery; then associated delay can be measured in number of person days / or IEH
Applicability: SCRUM
5) Innovation
The number of innovative ideas/best practices adopted to deliver out of box solution with in iteration. It might be good design strategy, improved code quality, increased automation by using good tools under all stages of SDLC cycle etc. Again it is in process matrix collection mechanism, Scrum Master is the best person to judge such initiatives.
Applicability: SCRUM, Workshops, Continuous Integration
6) No of Reusable components to the organization
How many reusable components are contributed to the organization from the project? Here code is fully tested and moved to client’s production environment. Any such code which does not have any customer obligations shall be moved organization’s reusable component repository. It can be measured across the projects over the period of time. This measurement shall be conducted against iteration or specific period of time.
Applicability: SCRUM, Agile process as a whole
7) Increased knowledge sharing activities
How many times from specific SCRUM team member shared his technical competency with others in the form of presentations, trainings, articles etc. Any such instances shall be captured.
Applicability: SCRUM
8) Team engagement
Team engagement during sprint, shall be calculated in the form of Ideal Engineering Hours (IEH). Also overall team engagement in the form of understanding requirement, design, code, review, testing, training, research etc shall be classified.
Applicability: SCRUM (Backlogs)
9) Burn down charts
Burn down chart is early warning system, which gives product owner how the team is performing to achieve user story points for current iteration. At high level; number of high level warnings occurred during sprint / or across the sprint(s) shall be measured.
Applicability: SCRUM
10) Personal Excellence
Capture information such as how many people with in SCRUM team are being certified for various technological tools/frameworks? How many people participated seminars, training programs? How many team members contributed to open source projects or initiatives? Thus increase in company branding etc...
Applicability: SCRUM
11) Agile maturity
Judge the team maturity with help of schedule over run, effort over run (directly related to matured way of conducting task estimation), what kind of task selection from team member during iteration planning, active participation instances in various workshops, retrospective meetings, stick on to realization of sprint goals, adherence to multiple project checklists etc. Any violations or innovative ideas should be captured as part of sprint.
Applicability: SCRUM
12) Compliance with respect agile principles/or number of tailor made approaches which violates agile principle
Capture any agile principle violations in the form of tailor made requirements; might be influenced by external stakeholder. Also identify number of agile principles being practiced on iteration basis. Derive such matrix at the end of each iteration. In my opinion it is the most important activity shall be considered with high priority.
Applicability: SCRUM, Workshops, Continuous Integration
13) Obstacles cleared per iteration
Capture number of blockers removed per iteration.
Applicability: SCRUM
14) Number of De-scoped functions/tasks over into next iteration
All de-scoped story points of the current sprint
Applicability: SCRUM
15) Number of retrospectives per iteration
How often SCRUM teams adheres to “Inspect and Adapt” principle? Identify number of retrospectives being conducted with in sprint. Also capture what are the types of retrospective meetings are being practiced and related feedback from the team.
Applicability: SCRUM
16) Implementation status of retrospective action items
It is number of outstanding retrospective action items from previous sprints.
Applicability: SCRUM
17) Number of functional tests / iteration or user story
It is a process of capturing number of functional tests developed and applied against user story points per iteration.
Applicability: SCRUM, Continuous Integration
18) Unit tests / iteration
Capture number of unit test cases against code developed per sprint.
Applicability: SCRUM, Continuous Integration
19) Number of builds / iteration
Capture number of successful builds / or broken builds per sprint.
Applicability: SCRUM, Continuous Integration
20) Number of functional defects / iteration
It is number of functional defects found by both internal QC team and client.
Applicability: SCRUM, Continuous Integration
21) Lines of code
It is mainly concentrated on development team productivity on lines of code delivered for the specific period. For example; KLOC/Person day. But most of the agile practicing companies discourage this approach as 50 lines of code with just variable declarations can’t be more productive compare to just 20 lines of code which does important business functionality. In my opinion it is most crud way to measure productivity; shall be discarded.
Applicability: SCRUM, Continuous Integration
22) Function Point
It is originally intended to use for project estimation. It revolves under Input, Output (Report) and data. Again as explained with LOC; one can not depend on FP for measurement for the simple reason, a simple CRUD operation will carry more function point where in most complex business scenario which does not have any output will carry less FP. In my opinion each FP should have weightage and determination of weight-age will ask for definitive discussion.
Applicability: SCRUM
23) Velocity
Sustained development pace of the team is determined by Velocity mechanism. Here it depends on number of story points delivered per iteration. Most of the agile practitioners recommend this approach to determine overall team productivity. Here also some fundamental question arises like “if team of 3 delivers 40 story points where in another team of 10 delivers 50 story points, so which sprint team is more productive?”
Applicability: SCRUM
Linked-In QA
Stakeholder Interest
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/234124-14255949
EA best practices to Individual Projects
http://www.linkedin.com/answers/technology/enterprise-software/TCH_ENT/234126-14255949
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/234124-14255949
EA best practices to Individual Projects
http://www.linkedin.com/answers/technology/enterprise-software/TCH_ENT/234126-14255949
22 May, 2008
Dont justify agile based on productivity
It is often found that, many people adopt agile development process for quicker delivery. But it is thorough bad idea, with out understanding agile goals and true engineering practices. Productivity of an s/w person cant be measured in the form of lines of code, how many function point is delievered etc. Rather it will be more meaningful if it is associated like
Increased customer satisfaction (may conduct ratings)
Increase in the quality of delivery like no architectural issues under design phase, no design mistakes during production run, better quality code in context to better API usages, easier maintenance etc
Increased personal excellance in the form of better problem solving skills; communication with co-team members, external people
Contribution to online community, information sharing with in organization or outside organization
etc..etc..etc...many more
-
Increased customer satisfaction (may conduct ratings)
Increase in the quality of delivery like no architectural issues under design phase, no design mistakes during production run, better quality code in context to better API usages, easier maintenance etc
Increased personal excellance in the form of better problem solving skills; communication with co-team members, external people
Contribution to online community, information sharing with in organization or outside organization
etc..etc..etc...many more
-
Subscribe to:
Posts (Atom)