Chapter 3 Improving Software Economics.ppt

1、22,1,Chapter 3 Improving Software Economics,Part 2 of 2,22,2,Outline,3. Improving Team Effectiveness (5) 4. Improving Automation through SoftwareEconomics (3) 5. Achieving Required Quality (5) 6. Peer Inspections: A Pragmatic View (7),22,3,3. Improving Team Effectiveness,“It has long been understood

2、 that differences in personnel account for the greatest swings in productivity.” Great teams all stars not too good. Also impossible to manage. Wont happen. Best pragmatic approach: Balance highly talented people in key positions; less talented in other positions Coverage strong skill people in key

3、positions.,22,4,3. Improving Team Effectiveness - continued,Managing the team is the key. A well-managed team can make up for other shortcomings. Boehms recommendations: 1. Principle of top talent: use better and fewer people. Proper number of people is critical. 2. Principle of job matching (skills

4、 and motivations) Not uncommon in development teams for individuals to have a vision of promotion from programmer to project manager or to architect or to designerSkill sets are NOT the same and many projects have gone amuck due to poor management!Great programmers are not necessarily great managers

5、 and conversely.,22,5,3. Improving Team Effectiveness - continued,3. Principle of Career Progression Organization training will pay great dividends Posting for new jobs? What are the prime motivators and motivation?4. Principle of team balance dimensions;balance of: raw skills (intelligence, objecti

6、vity, creativity, analytical thinking) psychological makeup (leaders and followers; risk takers and conservatives; visionaries and nitpickers),22,6,3. Improving Team Effectiveness - continued, 5. Principle of Phase-out Get rid of the dead wood! Disrupt team balance; horribly de-motivating. Get rid o

7、f this person!,22,7,3. Improving Team Effectiveness continued (last),Overall team guidance:Essential ingredients: a culture of teamwork vice individual accomplishment. Teamwork and balance! Top talent and phase-out are secondary Obsession with career progression will take care of itself in the indus

8、try tertiary Strong, aware leadership is essential. Keeping team together; recognizing individual needs and excellent performers; nurturing newbees, considering diverse opinions, facilitating contributions from everyone; make them feel important all are essential for an effective project manager.,22

9、,8,4. Improving Automation Through Software Environments (1 of 3),The environment (tools) can dramatically impact productivity and effort and thus schedule and cost. Huge number of available tools in marketplace for supporting a process. Careful selection of the right combinations Recognize that the

10、se tools are the primary delivery vehicle for process automation. Mature software processes suggest that highly integrated tools and environment are necessary to facilitate the management of the process.,22,9,4. Improving Automation Through Software Environments cont. (2 of 3),Definition of the deve

11、lopment and maintenance environment is a first-class artifact of a successful process. Robust, integrated development! Hire good people and equip them with modern tools. A prime motivator: learning tools and environments of our profession! Yet todays environments still fall short of what they can be

12、. So much more is comingand coming and,22,10,4. Improving Automation Through Software Environments cont. (3 of 3),Be careful of tool vendor claims. (Can prove anything with statistics!) Remember, the tools must be integrated into the development environment. Authors suggests that in his experience,

13、the combined effect of all tools is less than 40% (5% for an individual tool) and most benefits are NOT realized without a corresponding change in the process that will require their use. But this is substantial!,22,11,Achieving Required Quality (1 of 5),Many of the items we have discussed not only

14、favorably affect the development process but impact overall quality. (Remember this statement for questions ahead) Author presents a rather comprehensive table p. 49 for our consideration: This table represents General Quality improvements realizable with a modern practice:,22,12,22,13,5. Achieving

15、Required Quality continued (3 of5 ),Additional overall quality factors: 1. Focus on requirements driving the process namely: address critical use cases early and traceability late in the life cycle. Balance requirements, development and plan evolution 2. Use metrics / indicators to measure progress

16、and quality of the architecture as it evolves from a high-level prototype to a fully compliant product Remember: the architecture drives much of the process! Discuss. What does it drive? How do you think we measure this progress?,22,14,5. Achieving Required Quality continued (4 of 5),Additional over

17、all quality factors 3. Provide integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automation 4. Use visual modeling and HLL that support architectural control, abstraction, d

18、esign reuse 5. Continually look into performance issues. Require demonstration-based evaluations. Think: HOW are these so? Can you answer?,22,15,5. Achieving Required Quality continued (last),Performance issues: Be careful with commercial components and custom-built components Assessment of performa

19、nce can degrade as we progress through our process. Planned, managed demonstration-based assessments the way to go. WHY do you think this is so? Particularly true to demonstrate EARLY architectural flaws or weaknesses in commercial components where there is time to make adjustments,22,16,6. Peer Ins

20、pections: A Pragmatic View,An old way asserted to yield super results. - Just dont provide the return desired in todays complex systems. Good in some cases such as to nurture less-experienced team members Catch the real bad blunders early. Inspections can be applied at various times during a cycle.

21、Consider:,22,17,6. Peer Inspections: A Pragmatic View continued (2 of 7), 1. INSPECTIONS FOR: Transitioning engineering info from one artifact set to another, thereby assessing the consistency, feasibility, understandability, and technology constraints inherent in the engineering artifacts. Example:

22、 analysis classes will morph into design classes which will typically become part of packages or components In doing so, have we lost, for example, the desired functionality? If the functionality is accommodated by a number of design model elements, can you ensure that the functionality is NOT lost?

23、 Can you TRACE it? Discuss.,22,18,6. Peer Inspections: A Pragmatic View (3 of 7), 2. INSPECTIONS: Major milestone demonstrations Force artifact assessment against tangible criteria for relevant use cases 3. INSPECTIONS using Environment tools 4. Life-cycle testing provides insight into requirements

24、compliance 5. INSPECTIONS: Study Change Management metrics must manage Change and how change requests might impact both quality and progress goals.,22,19,6. Peer Inspections: A Pragmatic View (4 of 7),Overall: Ensure that critical components are really looked at by the primary stakeholders. Cannot r

25、eally look at all artifacts. Inspecting too many artifacts will not be cost-effective on the contrary! Many artifacts dont deserve / merit close scrutiny and most inspections tend to be quite superficial.,22,20,6. Peer Inspections: A Pragmatic View (5 of 7),Love this: Many highly complex application

26、s have demanding dimensions of complexity which include innumerable components, concurrent execution, distributed resources, and more. Most inspections thus end up looking at style and first-order semantic issues rather than real issues of substance. Discuss technical / managerial reviews,22,21,6. P

27、eer Inspections: A Pragmatic View (6 of 7),Most major difficulties such as performance, concurrency, distribution, etc. are discovered through activities such as: Analysis, prototyping, and experimentation Constructing design models (can see requirements missing; can see architectural constraints un

28、accounted) Committing the current state of the design to an executable implementation Demonstrating the current implementation strengths and weaknesses in the context of critical subsets of use cases and scenarios Incorporating lessons learned back into the models, use cases, implementations, and pl

29、ans.,22,22,6. Peer Inspections: A Pragmatic View - last,Remember: the RUP is (among other things) architecture-centric, use-case driven, iterative development process.Iterations are planned to address (decreasing) priorities: risk and core functionalities as identified in Use Cases and Supplementary

30、 Specifications (=SRS) This iterative process evolves the architecture through the phases especially and mainly elaboration.Each phase has milestones and focus on inspecting critically-important issues. Overall there is very questionable ROI on meetings, inspections, or documents. Quality assurance is every stakeholders responsibility.,