This action might not be possible to undo. Are you sure you want to continue?
MCA II Semester
Effective software project management focuses on 4 P¶s:
People ± the most important element of a successful project Product ± the software to be built Process ± the set of framework activities and software engineering tasks to get the job done Project ± all work required to make the product a reality
MCA II Semester 2
³Companies that sensibly manage their investment in people will prosper in the long run´ Quote by Tom DeMarco & Tim Lister Importance of ³people factor´ in successful project management PM-CMM ± Key Practice Areas Recruitment Selection Performance Management Training Compensation Career Development Organization and work design Team/Culture Development
MCA II Semester
Stakeholders Senior Managers Define the business issues that often have significant influence on the project Project (Technical) Managers Plan. organize and control the practitioners who do software 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 End-users Interact with the software once it is released 20-Jan-12 MCA II Semester 4 . motivate.
Team Leader The MOI Model of leadership Motivation By ³push or pull´ Organization To enable the initial concept to be translated into a final product Ideas or innovation Even with constraints of software product or application 20-Jan-12 MCA II Semester 5 .
Characteristics of Project Manager Problem solving Managerial identity Achievement ± self and of the team Influence and team building ± remain under control in high-stress situations 20-Jan-12 MCA II Semester 6 .
Software Teams How to lead? How to organize? How to collaborate? How to motivate? How to create good ideas? 20-Jan-12 MCA II Semester 7 .
Team Organizations Democratic decentralized (DD) No permanent leader. only ³task coordinators´ Controlled decentralized (CD) A leader and many secondary leaders for subtasks Controlled Centralized (CC) Well defined team leader Communication between the leader and team members is vertical 20-Jan-12 MCA II Semester 8 .
Software Teams When selecting a software project team structure consider The difficulty of the problem to be solved Size of the resultant program(s) in lines of code or function points Time that the team will stay together (team lifetime) Degree to which the problem can be modularized Required quality and reliability of the system to be built The rigidity of the delivery date The degree of sociability (communication) required for the project 20-Jan-12 MCA II Semester 9 .
Open paradigm Combines both 1 & 2 Control like closed paradigm & Innovation like the random paradigm 20-Jan-12 MCA II Semester 10 . Closed paradigm Structures a team along a traditional hierarchy of authority 2. Random paradigm Structures a team loosely and depends on individual initiative of the team members 3.Organizational Paradigms for Teams 1.
Organizational Paradigms for Teams 4. Synchronous paradigm Relies on the natural compartmentalization of the problem Organizes team members to work on modules of the problem Little active communication among team members Suggested by Constantine 20-Jan-12 MCA II Semester 11 .
business.Avoid Team ³Toxicity´ A frenzied work atmosphere Team members waste energy and lose focus on the objectives of the work to be performed High frustration caused by personal. or technological factors that cause friction among team members ³Fragmented or poorly coordinated procedures´ A poorly defined or improperly chosen process model that becomes a roadblock to accomplishment Unclear definition of roles Will result in a lack of accountability & finger-pointing ³Continuous and repeated exposure to failure´ Leads to a loss of confidence and a lowering of morale. 20-Jan-12 MCA II Semester 12 .
and synchronous paradigms Significant autonomy 20-Jan-12 MCA II Semester 13 . if team cohesiveness is to be maintained Team is ³self-organizing´ An adaptive team structure Uses elements of Constantine¶s random.Agile Teams Team members must have trust in one another The distribution of skills must be appropriate to the problem Mavericks may have to be excluded from the team. open.
impersonal approaches Work products Formal. work product reviews Informal. interpersonal procedures Status review meetings. interpersonal procedures Group meetings Electronic communication Electronic mail. video-based conferencing systems. Interpersonal networking Informal discussions with team members and outsiders 20-Jan-12 MCA II Semester 14 .Team Coordination & Communication Formal.
2. project plan needs to be prepared immediately 20-Jan-12 MCA II Semester 15 . Product Challenge of a software project manager at the beginning of a project A detailed analysis of software requirements takes longer time Requirements may change regularly Yet.
Information objectives Customer±visible data objects as input and output of the software 3. 20-Jan-12 MCA II Semester 16 . Context Software to be built fits into a larger system Constraints of the larger system into the new software Interfaces Reliability 2.The Product Scope 1. Function and performance Refers to processing and response time requirements Software project scope must be unambiguous and understandable at the management and technical levels.
The problem is that those writing them probably didn¶t fully understand. 20-Jan-12 MCA II Semester 17 . not just what she/he thinks they want. Beware if one provides detailed written specifications on what they want. Have free form discussion Try to understand his/her goals/constraints.The Product Scope Obtaining the information Communication. communication!!! Meet with customer as often as needed. and they will change. communication.
20-Jan-12 MCA II Semester 18 .The Scope Information ± Questions Overall Goals Who¶s request What benefit Who else has solution Understanding The Problem What output What Problem What Issues What Constraints Effectiveness of Meeting Are answers official Are my questions relevant Other sources of Info.
Scoping ± Subsequent Meetings Begin high level planning Know the capabilities of existing software and staff Joint teams of customer and developers/analysts Checklist of items to cover Organization of Information Get everything down with diagrams Create and save transcripts of Meetings Possibly use Web 20-Jan-12 MCA II Semester 19 .
Problem Decomposition Sometimes called partitioning or problem elaboration 1. Problem is decomposed into constituent functions 2. Decomposed into user-visible data objects or a set of problem classes Decomposition process continues until all functions or problem classes have been defined 20-Jan-12 MCA II Semester 20 .
e. The Process Select a particular process model Establish a process framework considering Customers and the project team The project characteristics The project environment Define a task set for each software engineering activity.3.. i. Software engineering tasks Work products Quality assurance points Milestones 20-Jan-12 MCA II Semester 21 .
Melding the Product and Process 20-Jan-12 MCA II Semester 22 .
4. Deadlines are unrealistic. 7. 3. Software people don¶t understand their customer¶s needs The product scope is poorly defined Changes are managed poorly The chosen technology changes. The project team lacks people with appropriate skills. The Project Ten symptoms of a project in jeopardy: 1. 5. Sponsorship is lost [or was never properly obtained]. Managers [and practitioners] avoid best practices and lessons learned. Business needs change [or are ill-defined]. Users are resistant. 10. 20-Jan-12 MCA II Semester 23 . 2. 8. 4. 9. 6.
Approach to software projects Start on the right foot Maintain momentum Track progress Make smart decisions Conduct a postmortem analysis 20-Jan-12 MCA II Semester 24 .
by when? Who is responsible for a function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource is needed? 20-Jan-12 MCA II Semester 25 .The W5HH Principle Why is the system being developed? What will be done.
Critical Practices Formal risk management Empirical cost and schedule estimation Metric-based project management Earned value tracking Defect tracking against quality targets People-aware Program Management 20-Jan-12 MCA II Semester 26 .
Exercise 7 Do a first level functional decomposition of the ³page setup´ function of Microsoft Word software 20-Jan-12 MCA II Semester 27 .
Metrics & Indicators 20-Jan-12 MCA II Semester 28 .Software Engineering Measures.
Metric ± ³a quantitative measure of the degree to which a system, component, or process possesses a given attribute´ Metrics are a tool which can be used to improve the productivity and quality of the Software System There are four reasons for measuring software processes, products, and resources
To characterize To evaluate To predict To improve
20-Jan-12 MCA II Semester 29
1. Errors: Faults found by the practitioners during software development 2. Defects: Faults found by the customers after release
MCA II Semester
Software Metrics Domains
1. Product Metrics
Focus on the quality of deliverables Product metrics are combined across several projects to produce process metrics Examples:
Measures of the Analysis Model Complexity of the Design Model Internal algorithmic complexity Architectural complexity Data flow complexity (Code metrics)
MCA II Semester
Results in Statistical Software Process Improvement (SSPI) 20-Jan-12 MCA II Semester 32 . Strategic and Long Term. Process Metrics Focus on quality achieved as a consequence of a repeatable or managed process.Software Metrics Domains 2.
Error Categorization and Analysis:
All errors and defects are categorized by origin The cost to correct each error and defect is recorded The number of errors and defects in each category is computed Data is analyzed to find categories that result in the highest cost to the organization Plans are developed to modify the process ± Defect Removal Efficiency (DRE) DRE = E / (E + D) ± should be 1
MCA II Semester
Software Metrics Domains
3. Project Metrics
Used by a project manager and software team to adapt project work flow and technical activities
MCA II Semester
Project Metrics ± Purpose
Minimize the development schedule Avoid delays Assess status and product quality on an ongoing basis Track potential risks and mitigate problems (Uncover problem areas before they go ³critical´) Evaluate the project team¶s ability to control quality of software work products
MCA II Semester
Project Metrics ± Examples Effort or time per SE task Errors uncovered per review hour Scheduled Vs. actual milestone dates Number of changes and their characteristics Distribution of effort on SE tasks 20-Jan-12 MCA II Semester 36 .
A Good Manager Measures process process metrics project metrics measurement product metrics product What do we use as a basis? size? function? 20-Jan-12 MCA II Semester 37 .
Normalization for Metrics How does an organization measure & combine metrics that come from different individuals or projects? Depend on the size and complexity of the projects Normalization: compensate for complexity aspects particular to a product Normalization approaches: Size oriented (lines of code approach) Function oriented (function point approach) 20-Jan-12 MCA II Semester 38 .
Size ± Oriented Metrics Errors per KLOC (thousand lines of code) Defects per KLOC $ per LOC Page of documentation per KLOC Errors per person-month LOC per person-month $ per page of documentation 20-Jan-12 MCA II Semester 39 .
Qualify & Transform) 20-Jan-12 MCA II Semester 40 .Function ± Oriented Metrics (FP) Errors per FP Defects per FP $ per FP Pages of documentation per FP FP per person-month Variants more suitable for real-time and scientific software Extended FP or Feature Point Metrics 3D FP (Count.
These data are merely an indicator for process improvement Set clear goals and metrics Don¶t obsess on a single metric to the exclusion of other important metrics Beware of people performing to metrics rather than product quality or safety 20-Jan-12 MCA II Semester 41 .Software Metrics ± Summary Use common sense and organizational sensitivity Provide regular feedback to individuals and teams Don¶t use metrics to appraise individuals (Never use metrics to threaten individuals or teams) Problems != negative.
Integrity ± a system¶s ability to withstand attacks on its Security 4. Correctness ± the degree to which the software performs its required function 2.Measures of Software Quality 1. Usability ± an attempt to quantify ³user friendliness´ 20-Jan-12 MCA II Semester 42 . Maintainability ±the ease that a program can be corrected in case of changes 3.
Software Project Planning 20-Jan-12 MCA II Semester 43 .
Software Project Plan Scope ± understand the problem and the work that must be done.Software Project Planning Project Scope Estimates Risks Schedule Control strategy 1. 3. 5. Estimation ± how much effort? how much time? Risk ± what can go wrong? how can we avoid it? what can we do about it? Schedule ± how do we allocate resources along the timeline? what are the milestones? Control strategy ± how do we control quality? how do we control change? 20-Jan-12 MCA II Semester 44 . 4. 2.
2. Define Software Scope Determine Resources Create Project Estimates Make or buy decision 20-Jan-12 MCA II Semester 45 . 3. 4.Software Project Planning Objective : to provide a framework that enables the manager to make reasonable estimates of Resources Cost Schedule Steps: 1.
Project Resources 20-Jan-12 MCA II Semester 46 .
Duration of time that resource will be applied 20-Jan-12 MCA II Semester 47 . Time when the resource will be required 4. Description of the resource 2.Project Resources characteristics 1. A statement of availability 3.
Human Resources Scope and skills required Organizational position and specialty must both be considered Estimate of development effort (this is essential to determine the number of people required for the project) 20-Jan-12 MCA II Semester 48 .1.
2. Reusable Software Resources Off-the-shelf components Full experience components Partial experience components New components 20-Jan-12 MCA II Semester 49 .
Environmental Resources (SEE) Compilers Editors Design tools Configuration management tools Management tracking tools Problem Reporting And Corrective Action (PRACA) tools Documentation tools Hardware resources Network support 20-Jan-12 MCA II Semester 50 .3.
For example # of people = LOC ÷(Duration*(LOC/PM)) LOC = line of code PM = person month 20-Jan-12 MCA II Semester 51 .Software Project Estimation Estimation critical ± software costs usually dominate project Categories of estimation techniques Base estimates on similar projects Use simple decomposition Use one or more empirical models.
prioritizing and re-planning 20-Jan-12 MCA II Semester 52 . and plan accordingly (risk management) Don¶t leave critical activities to the last minute.g. everything takes much longer than expected Assess what can go wrong. e. Evaluating software system Printing final report Allow time for troubleshooting Keep monitoring.Estimation ± contingency planning Time is the enemy.
calendar time.Software Project Estimation The accuracy of a software project estimate is predicted based on: 1. 4. and dollars The degree to which the project plan reflects the abilities of the software team The stability of product requirements and the environment that supports the software engineering effort 2. The degree to which the planner has properly estimated the size of the product The ability to translate the size estimate into human effort. 3. 20-Jan-12 MCA II Semester 53 .
Change sizing Existing software modified as part of a project 20-Jan-12 MCA II Semester 54 .Decomposition Techniques Estimating the size of the project : Project sizing Techniques (by Putnam & Myers): 1. etc. ³Fuzzy logic´ sizing Uses approximate reasoning techniques / experiences 2. 3. Instructions. 4. reports. Function point sizing Standard component sizing Standard components like screens. LOC.
The scope of the project is not adequately understood or has been misinterpreted by the planner Productivity data used for problem-based estimation techniques is inappropriate MCA II Semester 55 2.Problem±Based Estimation LOC and FP methods Process Based Estimation method Decompose the process into a set of activities or tasks Estimate effort or cost to perform each task Estimate cost of each function Agreement between estimates could be poor due to 1. 20-Jan-12 .
make 3 estimates Optimistic Most likely Pessimistic Combine them as EV = (Sopt + 4*Sm + Spess)/6 20-Jan-12 MCA II Semester 56 . So.Software Project Estimation Precise estimation is difficult.
Empirical Estimation Models Uses empirically derived formulas to predict effort as a function of LOC or FP An empirical model based on project experience is COCOMO ± Constructive Cost Model Initial version published in 1981 Hierarchy of Models suggested by Barry Boehm 3 levels 20-Jan-12 MCA II Semester 57 .
regulations and operational procedures Moderate PM = 3.12* M Embedded PM = 3.0 (KLOC)1. project & team characteristics 20-Jan-12 MCA II Semester 58 .4 (KLOC)1.reflects product.20* M M.05* M Description Well-understood applications developed by small teams More complex projects where team members may have limited experience of related systems Complex projects where the software is part of a strongly coupled complex of hardware.6 (KLOC)1. software.COCOMO 81 Basic Model Project complexity Simple Formula PM = 2.
Post-architecture-stage model Used during the construction of the software More accurate estimate of the project size is possible. 20-Jan-12 MCA II Semester 59 . Early design stage model Used once requirements have been stabilized and basic software architecture has been established 3.COCOMO II Model Sub models are 1. scripting or DB programming Used during the early stages of software engineering & uses function / application points or size 2. Application composition model When the system is created from reusable components.
Screens (at the user interface) Reports Processing Components Each object instance is classified into 1. 3. 2. 2. 3. Simple Medium Difficult 20-Jan-12 MCA II Semester 60 .COCOMO Model II Application composition model uses object points Object point is an indirect software measure computed using number of 1.
COCOMO Model II estimated effort = NOP/PROD 20-Jan-12 MCA II Semester 61 .
Make/Buy Decision Decision tree analysis 20-Jan-12 MCA II Semester 62 .
Automated Estimation Tools Allow the planner to estimate cost and effort and to perform ³what-if´ analyses for important projects Generic functions of the tools 1. 4. 5. 3. Sizing of project deliverables Selecting project activities Predicting staffing levels Predicting software effort Predicting software cost Predicting software schedules MCA II Semester 63 20-Jan-12 . 6. 2.
Risk Management 20-Jan-12 MCA II Semester 64 .
and the uncertainty that choice itself entails 20-Jan-12 MCA II Semester 65 . opinion. action or places Risk involves choice.Introduction Risk is defined as a Possibility of loss & the degree of probability of such loss Possibility of a negative or undesirable outcome. user. Risk concerns future happenings Risk involves change. or stakeholder satisfaction. such as changes of mind. so a risk could negatively affect customer.
Characteristics of Risks Uncertainty May or may not happen Loss Unwanted consequences 20-Jan-12 MCA II Semester 66 .
Risk Management Process involving Identification of risk Assess its probability of occurrence Estimate its impact Establish a contingency plan should the problem actually occur 20-Jan-12 MCA II Semester 67 .
monitors the projects for likely risks Proactive Begins long before technical work is initiated Identification of potential risks Studies of probability Impact Priorities 20-Jan-12 MCA II Semester 68 .Risk Strategies Reactive Software team does nothing about risks until something goes wrong ³fire fighting mode´ At best.
Kinds of Risks 1. Technical Risks ± threaten the quality & timeliness of the product Design Implementation Interfacing Verification Maintenance 20-Jan-12 MCA II Semester 69 . Project Risks ± threaten the project plan Budgetary Schedule Personnel Resource Customer 2.
Business Risks ± threaten the viability of the software Market Strategic Management Budget Risks may be: Known Predictable Unpredictable 20-Jan-12 MCA II Semester 70 .Kinds of Risks 3.
Risk Identification A systematic attempt to specify threats to the project plan Prepare a Risk Item checklist 20-Jan-12 MCA II Semester 71 .
Product size Risks associated with the overall size of the software to be built or modified 2. 3.Risk Identification 1. Process definition Risks associated with the degree to which the software process has been defined and is followed by the development organization 20-Jan-12 MCA II Semester 72 . Customer characteristics Risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner. 4. Business impact Risks associated with constraints imposed by management or the marketplace.
Risk Identification 5. Staff size and experience Risks associated with the overall technical and project experience of the software engineers who will do the work 20-Jan-12 MCA II Semester 73 . Development environment Risks associated with the availability and quality of the tools to be used to build the product. 6. Technology to be built Risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system 7.
4. Have top software and customer managers formally committed to support the project? Are end-users enthusiastically committed to the project and the system/product to be built? Are requirements fully understood by the software engineering team and their customers? Does the software engineering team have the right mix of skills? Is the number of people on the project team adequate to do the job? 2. 5. 3.Assessing Project Risks Ask a number of questions 1. If any one of these questions is answered negatively risk management should start 20-Jan-12 MCA II Semester 74 .
Cost risk The degree of uncertainty that the project budget will be maintained 3. Support risk The degree of uncertainty that the software will be easy to correct. Schedule risk The degree of uncertainty that the project schedule will be maintained 20-Jan-12 MCA II Semester 75 .Risk Components 1. Performance risk The degree of uncertainty that the product will meet its requirements Be fit for its intended use 2. adapt and enhance 4.
3.Risk Components Impact of the risk drivers on the risk components: 1. 4. Negligible Marginal Critical Catastrophic 20-Jan-12 MCA II Semester 76 . 2.
Risk Projection Also called risk estimation Attempts to rate each risk in 2 ways The likelihood or probability that the risk is real The consequences of the problems associated with the risk. should it occur 20-Jan-12 MCA II Semester 77 .
Assess the Risk Examine the accuracy of the estimates Define a risk referent level & establish the referent point or break point 20-Jan-12 MCA II Semester 78 . Develop a Risk Table 2.Risk Projection ± Steps 1. Assess the Risk Impact 3.
Risk Table 20-Jan-12 MCA II Semester 79 .
Risk Table Sort the table by probability and by impact Define a cutoff line Drawn horizontally at some point in the table Implies that only risks that lie above the line will be given further attention Risks below the line are re-evaluated to accomplish second-order prioritization 20-Jan-12 MCA II Semester 80 .
3. Monitoring & Management 1. As the project proceeds monitor the risk factors Risk management and contingency planning When mitigation efforts have failed and that the risk has become reality 20-Jan-12 MCA II Semester 81 .RMMM Risk Mitigation. Develop a plan for risk mitigation For example: high staff turnover is noted as a project risk r1. 2.
software design features can be specified that will eliminate or control potential hazards 20-Jan-12 MCA II Semester 82 .Safety Risks & Hazards Software safety and hazard analysis Software quality assurance activities that focus on the identification and assessment of potential hazard that may impact software negatively and cause an entire system to fail If hazards can be identified early in the software engineering process.
Project Scheduling & Tracking 20-Jan-12 MCA II Semester 83 .
Introduction An appropriate process model is selected Software engineering tasks have been identified Amount of work and the number of People have been estimated Deadline is known and risks have been identified Next activity is Scheduling & Tracking To get the job done on time 20-Jan-12 MCA II Semester 84 .
Definition An activity that distributes estimated effort across the planned project duration by allocating the effort to software engineering tasks Macroscopic schedule Detailed schedule 20-Jan-12 MCA II Semester 85 .
Scheduling ± 2 Perspectives 1. Chronological bounds have been discussed but that the end-date is set by the software engineering organization The first situation is encountered far more frequently than the second 20-Jan-12 MCA II Semester 86 . An end-date for release of a computerbased system has already been established. 2.
milestones & deliverables Compute a TSS ± Task Set Selector using the adaptation criteria: Size of the project Number of potential users Mission criticality Application longevity Stability of requirements Ease of customer/developer communication Maturity of applicable technology Performance constraints Project staff 20-Jan-12 MCA II Semester 87 .Defining a Task Set A task set is a collection of software engineering work tasks.
Defining a Task Set The degree of Rigor of the project is determined using the computed TSS value Degrees of rigor Casual Structured Strict 20-Jan-12 MCA II Semester 88 .
Defining a Task Network Also called an activity network A graphic representation of the task flow for a project 20-Jan-12 MCA II Semester 89 .
20-Jan-12 . 3.PERT / CPM Two project scheduling methods that can be applied to software development Program Evaluation and Review Technique (PERT) Critical Path Method (CPM) The methods allow the software planner to 1. Determine the critical path ² the chain of tasks that determines the duration of the project Establish ³most likely´ time estimates for individual tasks by applying statistical models Calculate ³boundary times´ that define a time "window" for a particular task MCA II Semester 90 2.
duration. 20-Jan-12 MCA II Semester 91 . and start date for each task Individuals assigned to tasks A timeline chart ± Gantt chart ± is generated from the input A timeline chart can be developed for the entire project or separate charts can be developed for each project function or for each individual working on the project.Timeline Charts Inputs : Set of tasks (the work breakdown structure) Effort.
1. Milestone.Timeline Charts Work tasks I.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required. OCI defined Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete Isolate software elements Milestone: Software elements defined Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed Make quick estimate of size Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete week 1 week 2 week 3 week 4 week 5 I.1.1.2 I.1.7 I.8 20-Jan-12 MCA II Semester 92 .4 I.1.5 I.1.1.6 I.3 I.1.
Timeline Charts 20-Jan-12 MCA II Semester 93 .
Tracking the Schedule Conduct periodic project status meetings ± get progress and problems Evaluate the results of all reviews conducted throughout the software engineering process Determine whether formal project milestones have been accomplished on time Compare actual start-date to planned start-date for each project task Meet informally with practitioners to obtain their subjective assessment of progress and problems 20-Jan-12 MCA II Semester 94 .
technical staff & the customer Define risks and suggest risk aversion techniques Define cost and schedule for management review Provide an overall approach to software development for all people associated with the project Outline how quality will be ensured and change will be managed 2. 3.Project Plan The Software Project Plan is a document that must 1. 20-Jan-12 MCA II Semester 95 . 4. 5. Communicate scope and resources to software management.
Exercise 8 Explain CPM / PERT Techniques with appropriate examples 20-Jan-12 MCA II Semester 96 .
Explain a sample Gantt Chart 20-Jan-12 MCA II Semester 97 .Exercise 9 Make a demonstration of Microsoft Project.
SQA 20-Jan-12 MCA II Semester 98 .
Software Quality Assurance What is quality? Control of Variation ± from one project to another Minimize the difference between the predicted resources & the actual resources Testing program should cover a known percentage of the software Minimize the number of defects that are released to the field Minimize the differences in speed and accuracy 20-Jan-12 MCA II Semester 99 .
4. 3. 20-Jan-12 . 2. 5. 6. A quality management approach Effective software engineering technology Formal technical reviews A multi-tiered testing strategy Control of software documentation A procedure to ensure compliance with software development standards Measurement and reporting mechanisms MCA II Semester 100 7.Software Quality Assurance An umbrella activity that is applied throughout the software process Encompasses 1.
specifications & the design of the system Quality of conformance The degree to which the design specifications are followed during production Focused primarily on implementation 20-Jan-12 MCA II Semester 101 .Quality ± 2 kinds Quality of design Characteristics that designers specify for an item Encompasses requirements.
reviews & tests Includes a feedback loop to the process that created the work product Activities may be Fully automated Entirely manual Or a combination of automated tools and human interaction 20-Jan-12 MCA II Semester 102 .Quality Control Involves the series of inspections.
Quality Assurance Consists of the auditing and reporting functions of management Goal is to provide management with the data necessary to be informed about product quality 20-Jan-12 MCA II Semester 103 .
Prevention costs include Quality Planning Formal Technical Reviews Test Equipment Training 20-Jan-12 MCA II Semester 104 .Cost of Quality Incurred in the pursuit of quality or in performing quality-related activities Associated with Prevention Appraisal Failure 1.
Failure costs 1.Cost of Quality 2. Internal failure costs Defects are detected prior to shipment Rework Repair Failure mode analysis 20-Jan-12 MCA II Semester 105 . Appraisal costs In-process and inter-process inspection Equipment calibration and maintenance Testing 3.
Cost of Quality Failure costs 2. External failure costs Incurred when defects are found after the product has been shipped to the customer Complaint resolution Product return and replacement Help line support Warranty work 20-Jan-12 MCA II Semester 106 .
SQA Quality is conformance to Explicit functional & performance characteristics Development standards Implicit characteristics SQA is Planned & systematic pattern of actions required to ensure quality in software SQA responsibility is with Software engineers Project managers Customers Salespeople SQA group The SQA group serves as the customer's in-house representative 20-Jan-12 MCA II Semester 107 .
SQA Activities An independent SQA group Prepares an SQA plan for the project Participates in the development of the project¶s software process description Reviews software engineering activities to verify compliance with the defined software process Audits designated software work products Ensures that deviations in software work and work products are documented & handled accordingly Records any noncompliance and reports to senior management 20-Jan-12 MCA II Semester 108 .
design. and coding Formal Technical Reviews An SQA activity performed by software engineers 20-Jan-12 MCA II Semester 109 .Software Reviews ± FTR A "filter" for the software engineering process Applied at various points during software development and serve to uncover errors and defects "purify" the software engineering activities ± analysis.
5.Objectives of FTR 1. logic. 6. or implementation of the software To verify that the software meets its requirements To ensure that the software has been represented according to predefined standards To achieve software that is developed in a uniform manner To make projects more manageable Also serves as a training ground for new engineers 20-Jan-12 MCA II Semester 110 . To uncover errors in function. 2. 3. 4.
FTR ± The Review Meeting Shall be conducted under the following constraints Between 3 and 5 people should be involved in the review Advance preparation should occur but should require no more than two hours of work for each person The duration of the review meeting should be less than two hours 20-Jan-12 MCA II Semester 111 .
Identifies problem areas within the product Serves as an action item checklist that guides the producer as corrections are made MCA II Semester 112 20-Jan-12 . 2. 2. What was reviewed? Who reviewed it? What were the findings and conclusions? Issues List: 1. 3.FTR ± Review Reporting A reviewer (the recorder) actively records all issues that have been raised Technical Review Summary Report & Review Issues List are prepared Review Summary Report: 1.
but don't attempt to solve every problem noted Take written notes Limit the number of participants and insist upon advance preparation Develop a checklist for each product that is likely to be reviewed Allocate resources and schedule time for FTRs Conduct meaningful training for all reviewers Review your early reviews 20-Jan-12 MCA II Semester 113 . 2. 8. 9. 4. 5.FTR ± Review Guidelines 1. not the producer Set an agenda and maintain it Limit debate and rebuttal Enunciate problem areas. 10. Review the product. 3. 7. 6.
Software Reliability The probability of failure-free operation of a computer program in a specified environment for a specified time A simple measure of reliability is meantimebetween-failure (MTBF) MTBF = MTTF + MTTR MTTF : mean-time-to-failure MTTR : mean-time-to-repair. not with the total error count 20-Jan-12 MCA II Semester 114 . An end-user is concerned with failures.
Software Availability The probability that a program is operating according to requirements at a given point in time Availability = [MTTF/(MTTF + MTTR)] * 100% The availability measure is more sensitive to MTTR. an indirect measure of the maintainability of software 20-Jan-12 MCA II Semester 115 .
SCM 20-Jan-12 MCA II Semester 116 .
Software Configuration Management A set of activities designed to control change An umbrella activity Different from Maintenance of a software Software Configuration ± items that comprise all information produced as part of the software process Computer programs Documents Data (contained within the program or external to it) 20-Jan-12 MCA II Semester 117 .
Origin of changes New business or market conditions Changes in product requirements or business rules New customer needs Modification of data or functionality Reorganization or business growth/downsizing Changes in project priorities or software engineering team structure Budgetary or scheduling constraints Redefinition of the system 20-Jan-12 MCA II Semester 118 .
Software Configuration Items Information that is created as part of the software engineering process 20-Jan-12 MCA II Semester 119 .
Baselines A specification or product that has been Formally reviewed and agreed upon Serves as the basis for further development Can be changed only through formal change control procedures 20-Jan-12 MCA II Semester 120 .
MCA II Semester
The SCM Process
Consists of 5 tasks
1. 2. 3. 4. 5.
Identification Version Control Change Control Configuration Auditing Reporting
MCA II Semester
Configuration Objects Documents ± Design Specification, Test Specification, Project Plan, « Source Code, Data Models, « Evolution Graph
MCA II Semester
RCS.Identification Tools used in SCM Rational ClearCase Microsoft VSS CCC. SCCS Maintenance of multiple versions Complete version maintenance Incremental maintenance Reverse incremental maintenance 20-Jan-12 MCA II Semester 124 .
Version Control Combines procedures and tools to manage different versions of configuration objects At each revision a composite object is stored Variants 20-Jan-12 MCA II Semester 125 .
Change Control Need for change is recognized Change request from user Developer evaluates Change report is generated Change Control Authority decides Request is queued for action. ECO generated 20-Jan-12 MCA II Semester Change request is denied 126 .
Access & Synchronization Control 20-Jan-12 MCA II Semester 127 .
2.Configuration Audit How can we ensure that a change has been properly implemented? 1. Formal Technical Reviews The Software Configuration Audit 20-Jan-12 MCA II Semester 128 .
4. 3. and reporting it been followed? Have all related SCIs been properly updated? 2.Configuration Audit The audit asks and answers the following questions 1. 6. 5. 20-Jan-12 MCA II Semester 129 . recording it. Has the change specified in the ECO been made? Have any additional modifications been incorporated? Has a FTR been conducted? Has the software process been followed? Has the change been "highlighted" in the SCI? Have the change date and change author been specified? Have SCM procedures for noting the change.
DODSTD-480A & MIL-STD-1521A : for software developed for military applications ANSI/IEEE No.Status Reporting & Standards Configuration status reporting answers the following questions 1. 3. What happened? Who did it? When did it happen? What else will be affected? SCM Standards MIL-STD-483. No. & No. 1042-1987. 10281988 : recommended for large & small SE organizations 20-Jan-12 MCA II Semester 130 . 828-1983. 2. 4.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.