Unit 4

September 6, 2011

Software Development And Management Spectrum

Project Management Spectrum

Project Management Focuses on Four Ps The People The Product The Process The Project Eective software project management focuses on these items (in this order)
The people

Deals with the cultivation of motivated, highly skilled people Consists of the stakeholders, the team leaders, and the software team.
The product

Product objectives and scope should be established before a project can be planned.
1

P.Selvapriyavadhana,Asst.Prof,ACT

The process

The software process provides the framework from which a comprehensive plan for software development can be established.
The project

Planning and controlling a software project is done for one primary reasonit is the only known way to manage complexity.In a 1998 survey, 26% of software projects failed outright, 46% experienced cost and schedule overruns
PEOPLE

The people factor is so important that the Software Engineering Institute has developed a people management capability maturity model (PM-CMM), to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability. The people management maturity model denes the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development. Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing eective software engineering practices. The PM-CMM is a companion to the software capability maturity model that guides organizations in the creation of a mature software process.

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 1: Management Spectrum

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

The people involved in management spectrum are: The Stake holders Team Leaders The Software Team
The Stakeholders

Five categories of stake holders Senior managers dene business issues that often have signicant inuence on the project. Project (technical) managers plan, motivate, organize, and control the practitioners who do the work. Practitioners deliver the technical skills that are necessary to engineer a product or application. Customers specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. End users interact with the software once it is released for production use.
Team Leaders

Competent practitioners often fail to make good team leaders; they just dont have the right people skills. Qualities to look for in a team leader Motivation the ability to encourage technical people to produce to their best ability Organization the ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a nal product
SQM 4

P.Selvapriyavadhana,Asst.Prof,ACT

Ideas or innovation the ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application. Team leaders should use a problem-solving management style: Concentrate on understanding the problem to be solved Manage the ow of ideas Let everyone on the team know, by words and actions, that quality counts and that it will not be compromised. Another set of useful leadership traits Problem solving diagnose, structure a solution, apply lessons learned, remain exible Managerial identity take charge of the project, have condence to assume control, have assurance to allow good people to do their jobs Achievement reward initiative, demonstrate that controlled risk taking will not be punished Inuence and team building be able to read people, understand verbal and nonverbal signals, be able to react to signals, remain under control in highstress situations

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

The Software Team

Seven project factors to consider when structuring a software development team 1. The diculty of the problem to be solved 2. The size of the resultant program(s) in source lines of code 3. The time that the team will stay together 4. The degree to which the problem can be modularized 5. The required quality and reliability of the system to be built 6. The rigidity of the delivery date 7. The degree of sociability (communication) required for the project Four organizational paradigms for software development teams 1. Closed paradigm traditional hierarchy of authority; works well when producing software similar to past eorts; members are less likely to be innovative 2. Random paradigm depends on individual initiative of team members; works well for projects requiring innovation or technological breakthrough; members may struggle when orderly performance is required 3. Open paradigm hybrid of the closed and random paradigm; works well for solving complex problems; requires collaboration, communication, and consensus among members 4. Synchronous paradigm organizes team members based on the natural pieces of the problem; members have little communication outside of their subgroups
SQM 6

P.Selvapriyavadhana,Asst.Prof,ACT

Five factors that cause team toxity (i.e., a toxic team environment) Toxic work environments can only exist where a lack of trust and this can only occur in the absence of sound leadership. 1. A frenzied work atmosphere 2. High frustration that causes friction among team members. 3. A fragmented or poorly coordinated software process. 4. An unclear denition of roles on the software team. 5. Continuous and repeated exposure to failure. How to avoid these problems Give the team access to all information required to do the job. Do not modify major goals and objectives, once they are dened, unless absolutely necessary. Give the team as much responsibility for decision making as possible. Let the team recommend its own process model. Let the team establish its own mechanisms for accountability (i.e., reviews). Establish team-based techniques for feedback and problem solving.

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Three generic team structures:

1. Democratic Decentralized (DD). 2. Controlled Decentralized (CD). 3. Controlled Centralized (CC).

Democratic Decentralized (DD)

No permanent leader. Task coordinators are appointed for short durations. Decisions are made by group consensus. For less understood and complicated problems. Good for low modularity. Suited for long term projects, because the amount of intra group communication that it encourages, leads to a longer development time. Not appropriate for large team due to communication overhead.
Controlled Decentralized (CD)

A dened leader who coordinates specic tasks. Secondary leaders that have responsibility for the individual groups. Problem solving is a group activity; distribution of tasks among subgroups is done by the team leader. For well understood tasks. For large projects Highly modular projects.

SQM

P.Selvapriyavadhana,Asst.Prof,ACT

Controlled centralized (CD)

Top-level problem solving and internal team coordination are managed by a team leader. Communication between the leader and team members is vertical. Used for simple problems. For large projects. For highly modular projects.
PRODUCT:

Before a project can be planned, product objectives and scope should be established, alternative solutions should be considered and technical and management constraints should be identied. Without this information, it is impossible to dene reasonable (and accurate) estimates of the cost, an eective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress. The software developer and customer must meet to dene product objectives and scope. Objectives identify the overall goals for the product without considering how these goals will be achieved. Scope identies the primary data, functions and behaviors that characterize the product, and more important, attempts to bound these characteristics in a quantitative manner. Once the product objectives and scope are understood, alternative solutions are considered.
SQM 9

P.Selvapriyavadhana,Asst.Prof,ACT

Problem decomposition Also referred to as partitioning or problem elaboration Sits at the core of software requirements analysis. A complex problem is partitioned into smaller problems that are more manageable. Two major areas of problem decomposition 1. The functionality that must be delivered. 2. The process that will be used to deliver it.
The Process

1. Getting Started 2. The project manager must decide which process model is most appropriate based on the customers who have requested the product and the people who will do the work. 3. The characteristics of the product itself. 4. The project environment in which the software team works. 5. Project planning begins as a melding of the product and the process based on the various framework activities 6. Once a process model is selected, a preliminary project plan is established based on the process framework activities. 7. Process decomposition then begins. 8. The result is a complete plan reecting the work tasks required to populate the framework activities.
SQM 10

P.Selvapriyavadhana,Asst.Prof,ACT

9. Process provides the framework from which a comprehensive plan for software development can be established. 10. Framework activities include tasks, milestones, work products and Quality Assurance etc.
Framework activities

1. Customer communicationtasks required to establish eective requirements elicitation between developer and customer. 2. Planningtasks required to dene resources, timelines, and other project related information. 3. Risk analysistasks required to assess both technical and management risks. 4. Engineeringtasks required to build one or more representations of the application. 5. Construction and releasetasks required to construct, test,install, and provide user support (e.g., documentation and training). 6. Customer evaluationtasks required to obtain customer feedback based on evaluation of the software representations created during the engineering activity and implemented during the construction activity.
THE PROJECT

In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. Indicate that an information systems project is in jeopardy(risk)
SQM 11

P.Selvapriyavadhana,Asst.Prof,ACT

software people dont understand their customers needs. The product scope is poorly dened. Changes are managed poorly The chosen technology changes. Business needs change. Deadlines are unrealistic. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices andlessons learned.
Five Common Sense Approach

1. Start on the right foot Understand the problem; set realistic objectives and expectations; form a good team 2. Maintain momentum Provide incentives to reduce turnover of people; emphasize quality in every task; have senior management stay out of the teams way 3. Track progress Track the completion of work products; collect software process and project measures; assess progress against expected averages

SQM

12

P.Selvapriyavadhana,Asst.Prof,ACT

4. Make smart decisions Keep it simple; use COTS or existing software before writing new code; follow standard approaches; identify and avoid risks; always allocate more time than you think you need to do complex or risky tasks 5. Conduct a post mortem analysis Track lessons learned for each project; compare planned and actual schedules; collect and analyze software project metrics; get feedback from teams members and customers; record ndings in written form . 2 The W5HH Principle

By Barry Boehm in 1966 in paper for software project managers.Applicable regardless of the size or complexity of a software project.Provides a planning outline for the project manager and software team.A series of questions are asked: 1. Why is the system being developed? Business reasons. Does the business purpose justify the expenditure of people, time and money? 2. What will be done? Establish the task set for the project. 3. When will it be done? Answer to this question helps the team to establish a project schedule by identifying when project tasks
SQM 13

P.Selvapriyavadhana,Asst.Prof,ACT

are to be conducted and when milestones are to be reached. 4. Who is responsible for a function? Describe role and responsibility of every member in the team. 5. Where they are organizationally located? They: customer, users, stakeholders. Not all roles and responsibilities reside within the software team itself. 6. How will the job be done technically and managerially? Once establishment of project scope is done, strategy for the project must be dened. 7. How much of each resource is needed? 3 CRITICAL PRACTICES

The Air lie Council has developed a list of critical software practices for performance-based management. These practices are consistently used by, and considered critical by, highly successful software projects and organizations. To enable a software organization to determine whether a specic project has implemented critical practices, the Air lie Council has developed a set of Quick Look questions for the project.
SQM 14

P.Selvapriyavadhana,Asst.Prof,ACT

1. Formal risk management What are the top ten risks for this project? For each of the risks, what is the chance that the risk will become a problem and what is the impact if it does? 2. Empirical cost and schedule estimation. What is the current estimated size of the application software (excluding system software) that will be delivered into operation? How was it derived? 3. Metric-based project management. Do you have in place a metrics program to give an early indication of evolving problems? If so, what is the current requirements volatility? 4. Earned value tracking. Do you report monthly earned value metrics? If so, are these metrics computed from an activity network of tasks for the entire eort to the next delivery? 5. Defect tracking against quality targets. Do you track and periodically report the number of defects found by each inspection (formal technical review) and execution test from program inception and the number of defects currently closed and open? 6. People-aware program management. What is the average sta turnover for the past three months for each of the suppliers/developers involved in the development of software for this system? Software project team cannot answer these questions or answers them inadequately; a thorough review of project practices is indicated .

SQM

15

P.Selvapriyavadhana,Asst.Prof,ACT

ISO 9001 And Capability Maturity Models ISO 9000/9001 CMM

Denition

A set of documents dealing with quality systems that can be used for external quality assurance purposes.

Development Written for Documents Pages long Documents

The Capability Maturity Model describes the principles and practices underlying software process maturity and intended to help software organizations improve the maturity of their software process. By The International By The Software EngiStandards Organiza- neering Institute. tion Wide range of industry Software industry Abstract Only 5 pages Detailed Over 500 pages The supplier to improve the internal software process. Quality policy is primarily addressed in Software Quality Assurance.

On the customer/supplier relationship to reduce a customers risk in choosing a supplier. Management Quality policy is deResponsibility ned, documented, understood, implemented, and maintained; that responsibilities and authorities for all personnel specifying, achieving, and monitoring quality be dened.
SQM 16

P.Selvapriyavadhana,Asst.Prof,ACT

ISO 9000/9001 Quality tem Sys- Requires documented quality system, included procedures and instructions, be established.

CMM

Procedures are addresses and assured in Software Quality Assurance. Software product Engineering tasks should be dened, integrated, and consistently performed. Contract Re- Contracts are reviewed Documented and review to determine whether viewed and the missing the requirements are requirements are claried. adequately dened, agree with the bid, and can be implemented. Process Con- Requires that produc- The procedures dening trol tion processes be de- the software production ned and planned. This process are distributed includes carrying out throughout the key proproduction under con- cess areas in the varitrolled conditions, ac- ous Activities Performed cording to documented practices. instructions. Servicing Requires that servicing Intended to be applied in activities be performed both the software develas specied. opment and maintenance environments,

SQM

17

P.Selvapriyavadhana,Asst.Prof,ACT

ISO 9000/9001 Concept

CMM

To follow a set of stan- To emphasize on achievdards to make success ing and improving its prorepeatable cess continuously. Requires that training needs be identied and that training be provided, since selected tasks may require qualied personnel. Records of training are maintained. Requires that quality records be collected, maintained, and dispositioned. Identied in the training and orientation practices in the Ability to Perform common feature.

Training

Quality Records

Testing and peer review practices in Software Product Engineering.

The criteria for getting ISO 9000/9001 certication Review the current operation and business structure of your facility. Provide an introductory session in ISO 9000/9001 requirements and instruct in the preparation of job descriptions and work instruction style documentation. Audit the completed job descriptions and work instructions and prepare the structure for the policies and procedures manual. Write the rst draft of the policy and procedures manual to meet ISO 9000/9001 standards incorporating the existing documented work instructions.
SQM 18

P.Selvapriyavadhana,Asst.Prof,ACT

Submit rst draft of manuals for review and approval. Prepare nal draft of documentation and audit manuals for compliance to ISO 9000/9001 requirements. Train sta on the policies, procedures and work instruction manuals and receive feedback as to the accuracy of the documentation. Conduct a simulated third party audit of the implemented Quality System utilizing qualied auditors. Make nal adjustments to the Quality System to prepare for certied third party audit. 5 Six sigma process

The term six sigma process comes from the notion that if one has six standard deviations between the process mean and the nearest specication limit. Six Sigma is about cost reduction by eliminating defects. Six Sigma uses the following three principles: 1. Focus on customers. 2. Process orientation. 3. Leadership based on metrics. Applying Six Sigma to software development makes software projects transparent to both management and customers. Transparency requires an important cultural change. As a result, after transparency is achieved, completing accurate project estimations while meeting both deadlines and customer requirements becomes a lot easier. Its objectives are to deliver products when promised, without delivered defects, early life failures, or failures during use.
SQM 19

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 2: six sigma process

SQM

20

P.Selvapriyavadhana,Asst.Prof,ACT

The Six Sigma approach is: (DMAIC) 1. Set the goal Dene 2. Dene the metrics Measure 3. Measure where you go Analyse 4. Improve your processes while you go Improve 5. Act immediately if going the wrong path Control The word is a statistical term that measures how far a given process deviates from perfection. DMAIC is an acronym that outlines an iterative set of processes and tools within the Six Sigma realm. Six Sigma is fundamentally a set of tools to address problems of process quality and consistency. This increase in performance and decrease in process variation leads to waste reduction and improvement in revenues, frees up cash ow, and increases protability and employee satisfaction. It stands for: 1. Dene the problem or opportunity 2. Measure the current state 3. Analyze the data to identify sources of variation and potential improvements 4. Improve the process by installing new or improved processes 5. Control the process so that the improvement is sustained

SQM

21

P.Selvapriyavadhana,Asst.Prof,ACT

Figure 3: six sigma process

SQM

22

P.Selvapriyavadhana,Asst.Prof,ACT

Zero-Defect

Zero-Defect Software Development (ZDSD) is a practice of developing software that is maintained in the highest quality state throughout the entire development process. The ten basic rules of ZDSD: 1. Test your product every day as you develop it, and x defects as soon as you nd them. Apply the daily build and smoke test. At the end of every day you work on your project, build the current version of your software, and test it for basic functionality. Microsoft enforces this policy religiously, using large teams to build each project on a daily basis. A programmer whose code breaks the build may be called in the middle of the night and must go back to work to x the problem immediately. For independent game developers working on small projects, this is far easier. At the end of each day, test your program for at least ten minutes. Make a list of anything you would consider a defect, and resolve to x all defects before implementing any new features. Once you nd a defect, xing it becomes your number one priority, and you avoid writing any new code until the defect is 100% eliminated. 2. Review your code regularly. When most people think of QA, they think of testing, but testing is actually one of the least cost-eective strategies for nding bugs. The most rigorous testing will typically nd less than 60% of all bugs in a program, and there are certain types of bugs that testing will rarely nd. Studies conducted at many large software organizations have concluded that code inspections are far more cost-eective than testing. A NASA study found that code reading detected
SQM 23

P.Selvapriyavadhana,Asst.Prof,ACT

almost twice as many defects per hour as testing. Whenever youve added a few hundred lines of new code to your project, set aside an hour or two to read over your work and look for mistakes. One hour of code review is equivalent to two or more hours of methodical testing. As you gain experience, keep a list of the types of defects you nd, and run down your list whenever reviewing new code. To nd even more defects, have someone else read your code as well. 3. Rewrite poor-quality modules. When you discover an obscure new bug, do you ever pray, Oh no! Please dont let it be in that module! We all have monster modules of legacy code that were written when we werent such seasoned programmers as we are today. Dont fear them; rewrite them. Often a better approach will only become clear when an inferior solution has already been implemented. This is certainly true for John Carmack, who coded dozens of dierent approaches when writing the Quake engine before discovering one that satised him. Defects will not be distributed evenly across your code. You will typically nd that 20% of your routines are responsible for 80% of your errors. In my programs it is normally the modules that interact with the hardware or with third-party drivers, especially DirectX, that are the most buggy. Raise your standards for those modules that seem to produce a never-ending supply of bugs, and take the time to rewrite them from scratch. You may nd that other intermittent bugs disappear completely as a result. 4. Assume full responsibility for every bug. 95% of all software defects are caused by the programmer. Only 1% of defects are hardware errors, and the remaining 4% are caused by the compiler, the OS, or other software. Never dismiss a potential bug;
SQM 24

P.Selvapriyavadhana,Asst.Prof,ACT

nd out the exact cause of any anomaly. When the Mars probe suered serious software glitches during its mission, it was learned that the same glitch had occurred only once during testing on earth, but the engineers dismissed it as a temporary hardware hiccup. Unless your hardware drinks soda, it does not hiccup. 5. Handle change eectively. You will always think of great new features to add after you have started coding. Carefully consider how each change will impact your pre-existing code. Poor integration of unanticipated features is a major cause of defects. 6. Rewrite all prototyping code from scratch. Sometimes you may quickly prototype a new feature to see if it will be viable. Often this is done by sacricing code quality in the name of rapid development. If you eventually decide to keep the feature, it is very tempting to simply tack on some basic error checking to the prototyping code. Dont fall into this trap. If you werent writing the code originally with quality as a priority, scrap the prototyping code, and re-implement the feature from scratch. Rapidly prototyped features that slip into the nal product are a major source of bugs because they are not subject to the same quality standards as the rest of the code. 7. Set QA objectives at the beginning of every project. Studies have shown that developers who set reasonable QA goals will usually achieve them. Decide in advance if your product must be fast, small, feature-rich, intuitive, scalable, etc. Then prioritize those objectives. When designing the interface code for an upcoming game, I decided that my top three priorities were to make it beginner-intuitive, fast, and fun, in that order. Consequently, my games interface isnt as graphically rich as other games, but
SQM 25

P.Selvapriyavadhana,Asst.Prof,ACT

it is easier to use and faster than any other game of its type. Whenever you have to make a design decision, keep your objectives in mind. If you do not set clear QA goals, then you are doomed to accept the results of random chance. 8. Dont rush debugging work. Fully 50% of all bug xes are done incorrectly the rst time, often introducing new bugs in the process. Never experiment by simply changing x-1 to x+1 to see if that will do the trick. Take the time to understand the source of the bug. Long ago when I was a boy scout and had to put out a campre, the Scoutmaster would sometimes test my thoroughness by asking me to put my hand in the ashes. I learned very quickly how to put out a re so well that I had complete condence it was 100% extinguished. When you nd a defect, it means your code is on re. As long as the defect remains, any new code you write will add fuel to that re. Whenever you nd a defect, drop everything to x it, and dont move on until you are 100% condent that your x is correct. If you dont take the time to do it right the rst time, when will you nd the time to do it over? 9. Treat the quality of your code at the same level of importance as the quality of your product. Rate your code on a scale of one to ten for overall quality. The rst time I did this, I rated my 30,000-line project as a four. I rewrote the worst of the code until I reached an eight overall. It was one of the best investments of time I ever made because I was then able to add new features at double my previous rate. The quality of your code is highly indicative of the quality of your product. You may nd as I have that your best selling products also receive your highest ratings for code quality.
SQM 26

P.Selvapriyavadhana,Asst.Prof,ACT

10. Learn from every bug; each one represents a mistake that you made. Learn why you made each mistake, and see if you can change something about your development practices to eliminate it. Over the years I have adopted many simple coding practices that allow me to avoid common bugs that used to plague me. There are many types of bugs that I now never encounter because my coding style makes it physically impossible for me to introduce them. Each of these rules represents a simple concept, but their combined benets are signicant. You will achieve higher progress visibility, avoiding the situation of being 99% done for the last 80% of your development time. Higher quality will make your products easier to maintain and less expensive to support. 7 Statistical quality control

Statistical quality control (SQC) is the term used to describe the set of statistical tools used by quality professionals. Statistical quality control can be divided into three broad categories: 1. Descriptive statistics. 2. Statistical process control (SPC) 3. Acceptance sampling
Descriptive statistics

Descriptive statistics are used to describe quality characteristics and relationships. Included are statistics such as
SQM 27

P.Selvapriyavadhana,Asst.Prof,ACT

the mean, standard deviation, the range and a measure of the distribution of data.
Statistical process control (SPC)

Statistical process control (SPC) involves inspecting a random sample of the output from a process and deciding whether the process is producing products with characteristics that fall within a predetermined range. SPC answers the question of whether the process is functioning properly or not.
Acceptance sampling

Acceptance sampling is the process of randomly inspecting a sample of goods and deciding whether to accept the entire lot based on the results. Acceptance sampling determines whether a batch of goods should be accepted or rejected.

SQM

28