SlideShare a Scribd company logo

Se lect11 btech

Download as PPT, PDF
••
IIITA, profile picture
IIITA

Here are some common ways activities are organized in projects: - By project phase (e.g. requirements, design, development, testing) - By deliverable (e.g. requirements document, design specs, code) - By work package (e.g. user interface design, database development) - By component or subsystem (e.g. billing module, reporting features) - By task type (e.g. coding, documentation, testing) Organizing activities around milestones helps ensure the project stays on track to complete key checkpoints by certain dates. This provides regular opportunities for oversight and redirection if needed.

EducationTechnologyBusiness
1 of 90
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
IEEE Std 830-1998 Characteristics of a good SRS 1. Correct 6. Verifiable 2. Unambiguous 7. Modifiable 3. Complete 8. Traceable 4. Consistent 5. Ranked for importance and/or stability
IEEE Std 830-1998: Parts of an SRS • Introduction – Purpose • purpose of SRS • intended audience for SRS – Scope • identify software to be produced by name • explain what software will (not) do • describe application of software (benefits, objectives)
IEEE Std 830-1998: Parts of an SRS • Introduction (continued) – Definitions/acronyms/abbreviations – References • list documents referenced by name and source – Overview • brief description of rest of SRS • organization of SRS
IEEE Std 830-1998: Parts of an SRS • Overall description – Product perspective (related products?) • block diagram • constraints – system interfaces » identify functionality that fulfills each system requirement – user interfaces – hardware interfaces – software interfaces » how software interacts with supporting software (purpose, message content and format) » required versions
IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Product perspective • constraints – communications interfaces » network protocols – memory » requirements/limits on primary and secondary memory – operations » modes of operation » interactive vs. unattended operation » backup & recovery – site adaptation requirement
IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Product functions • summary of major functions sw will perform – Intended user characteristics • educational level • experience • technical expertise
IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Constraints (limitations of developer options) • regulatory policies • hardware limitations (e.g. signal timing requirements) • interfaces to other applications • parallel operation • audit functions • control functions • higher-order language requirements • reliability requirements • criticality of the application • safety and security considertations
IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Assumptions and dependencies • e.g. specific OS available on HW – Apportioning of requirements • requirements that may be delayed to future versions
IEEE Std 830-1998: Parts of an SRS • Specific requirements – External interfaces – Functions – Performance requirements – Logical database requirements – Design constraints • Standards compliance
IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) – Software system attributes • Reliability • Availability • Security • Maintainability • Portability
IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) – Organizing the specific requirements • System mode • User class • Objects • Feature • Stimulus • Response • Functional hierarchy – Additional comments
IEEE Std 830-1998: Parts of an SRS • Supporting Information – Table of contents – Index – Appendixes
Feasibility Study
Feasibility Study • A feasibility study is a study made before committing to a project. • A feasibility study leads to a decision: • go ahead • do not go ahead • think again • In production projects, the feasibility study often leads to a budget request. • A feasibility study may be in the form of a proposal.
Contents of Feasibility Study Client: Who is this project for? Scope: What are the boundaries of the project? Benefits: What are the benefits? Can they be quantified? Technical: Is the project possible. Is there at least one technical way to carry out the project? Resources: What are the estimates of staff, time, equipment, etc? Alternatives: What are the options if the project is not begun?
Feasibility Report A written document • For a general audience: client, financial management, technical management, etc. • Short enough that everybody reads it. • Long enough that no important topics are skipped. • Details are often included in supporting documents. It should be a well written, well presented document.
Types of Feasibility • Economic feasibility • Technical feasibility • Operational feasibility • Schedule feasibility • Legal and contractual feasibility • Political feasibility
Economic Feasibility • Cost-benefit analysis – identify all the financial benefits and costs associated with a project – Tangible vs. intangible benefits – Tangible vs. intangible costs – One-time vs. recurring costs
Technical Feasibility • Assessing the organization’s ability to construct the proposed system • Takes into account various project risk factors
Other Feasibility Concerns • Operational – Will the system achieve the objectives of the project? • Schedule – Can the project be accomplished in a reasonable time frame? – Project management critical path scheduling can help answer this concern. • Legal/Contractual – Are there regulations or legal obligations that affect the success of the project? • Political – Will the project have user and management support? – Will there be resistance?
SOFTWARE PROJECT MANAGEMENT
What are the Software Project management issues….
Software Project management • Software Project Management includes – Planning – Organizing – Monitoring – & Controlling Software Projects.
Issues to be handled under SPM
Issues to be handled under SPM – People, – Process, – And Problem – Software metrics – Software project – Software process – Software team – Risk
Issues to be handled under SPM • How must the – people, – process, – and problem be managed during a software project? • What are software metrics and how can they be used to manage a software project and the software process?
Issues to be handled under SPM • How does a software team generate reliable estimates of effort, cost, and project duration? • What techniques can be used to formally assess the risks that can have an impact on project success?
Issues to be handled under SPM • How does a software project manager select the set of software engineering work tasks? • How is a project schedule created? • How is quality defined so that it can be controlled? • What is software quality assurance? • Why are formal technical reviews so important? • How is change managed during the development of computer software and after delivery to the customer?
Who does Software Project Management
Who does Software Project Management • Everyone “manages” to some extent, but the scope of management activities varies with the person doing it. • A software engineer manages his day-to-day activities, planning, monitoring, and controlling technical tasks. • Project managers plan, monitor, and control the work of a team of software engineers. • Senior managers coordinate the interface between the business and the software professionals
Why Software Project Management is important
Why Software Project Management is important • Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time.
The 4 P’s
The 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 34
The 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”
People management capability maturity model (PM-CMM) • The people management maturity model defines the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development.
The 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 identified. • Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress.
The Process • A software process provides the framework from which a comprehensive plan for software development can be established. A number of different task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.
The Project • In 1998, industry data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns. • In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project.
Who are the Stakeholders in SPM
Who are the Stakeholders in SPM • Senior managers who define the business issues that often have significant influence on the project. • Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. • Practitioners who deliver the technical skills that are necessary to engineer a product or application. • Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. • End-users who interact with the software once it is 41 released for production use.
What is MOI model of leadership
What is MOI model of leadership • Motivation. The ability to encourage (by “push or pull”) 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 final product. • 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.
Types of Software Team
Types of Software Team • Mantei [MAN81] suggests three generic team organizations: • Democratic decentralized (DD). This software engineering team has no permanent leader. Rather, "task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks.“ • Communication within the team is horizontal.
Types of Software Team • Controlled decentralized (CD). This software engineering team has a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks. – Problem solving remains a group activity, but implementation of solutions is partitioned among subgroups by the team leader. – Communication among subgroups and individuals is horizontal. Vertical communication along the control hierarchy also occurs.
Types of Software Team • Controlled Centralized (CC). Top-level problem solving and internal team coordination are managed by a team leader. Communication between the leader and team members is vertical.
What are the Project coordination techniques • Formal, impersonal approaches include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. • Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections.
What are the Project coordination techniques • Informal, interpersonal procedures include group meetings for information dissemination and problem solving sessions for development staff. • Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. • Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.
Motivation behind the selection of Software Teams
Motivation behind the selection of Software Teams • The difficulty of the problem to be solved • The size of the resultant program(s) in lines of code or function points • The time that the team will stay together (team lifetime) • The degree to which the problem can be modularized • The 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 51
What is the Product Scope….
What is the Product Scope…. • Scope • Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? • Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? • Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? • Software project scope must be unambiguous and understandable at the management and 53 technical levels.
What is Problem Decomposition • Sometimes called partitioning or problem elaboration • Once scope is defined … – It is decomposed into constituent functions – It is decomposed into user-visible data objects or – It is decomposed into a set of problem classes • Decomposition process continues until all functions or problem classes have been defined 54
When the Project get into trouble….
The Project get into trouble when … • Software people don’t understand their customer’s needs. • The product scope is poorly defined. • Changes are managed poorly. • The chosen technology changes. • Business needs change [or are ill-defined]. • Deadlines are unrealistic. • Users are resistant. • Sponsorship is lost [or was never properly obtained]. • The project team lacks people with appropriate skills. • Managers [and practitioners] avoid best practices and 56 lessons learned.
THE W5HH PRINCIPLE: A way of analysis
THE W5HH PRINCIPLE: A way of analysis It includes a series of questions that lead to a definition of key project characteristics and the resultant project plan: • Why is the system being developed? • What will be done? • When will it be accomplished? • Who is responsible? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, 58 tools, database) will be needed?
Why SPM is different... • The product is intangible. • The product is uniquely flexible. • Software engineering is not recognized as an engineering discipline with the sound status as mechanical, electrical engineering, etc. • The software development process is not standardised. • Many software projects are ‘never-to -be- repeated' projects
Types of project plan
Types of project plan Plan Description Quality plan Describes the quality procedures and standards that will be used in a project. Validation plan Describes the approach, resources and schedule used for system validation. Configuration Describes the configuration management management plan procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan. Describes how the skills and experience of the project team members will be developed.
Project plan structure • Introduction • Project organisation • Risk analysis • Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms
Activity organization
Activity organization • Activities in a project should be organised to produce tangible outputs for management to judge progress • Milestones are the end-point of a process activity • Deliverables are project results delivered to customers • The waterfall process allows for the straightforward definition of progress milestones
Milestones in the SE process
Milestones in the SE process ACTIVITIES Feasibility Requir ements Prototype Design Requir ements study analysis development study specification Feasibility Requir ements Evaluation Architectural Requir ements report definition report design specification MILESTONES
Project scheduling
Project scheduling • Split project into tasks and estimate time and resources required to complete each task • Organize tasks concurrently to make optimal use of workforce • Minimize task dependencies to avoid delays caused by one task waiting for another to complete • Dependent on project managers intuition and experience
The project scheduling process Identify Identify activity Estimate resources Allocate people Create project activities dependencies for activities to activities charts Software Activity charts requirements and bar charts
Common Scheduling problems:
Scheduling problems; why it occurs. • Estimating the difficulty of problems and hence the cost of developing a solution is hard • Productivity is not proportional to the number of people working on a task • Adding people to a late project makes it later because of communication overheads • The unexpected always happens. Always allow contingency in planning
Bar charts and activity networks • Graphical notations used to illustrate the project schedule • Show project breakdown into tasks. – Tasks should not be too small. – They should take about a week or two • Activity charts show task dependencies and the critical path • Bar charts show schedule against calendar time
Task durations and dependencies Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)
Activity network 14/7/99 15 days 15 days M1 T3 8 days T9 T1 5 days 4/8/99 25/8/99 25/7/99 T6 M4 M6 4/7/99 M3 start 20 days 7 days 15 days T7 T11 T2 25/7/99 10 days 11/8/99 5/9/99 10 days M2 M7 M8 T4 T5 15 days T10 10 days 18/7/99 T12 M5 25 days T8 Finish 19/9/99
Activity timeline 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish
Staff allocation 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred T4 T8 T11 T12 Jane T1 T3 T9 Anne T2 T6 T10 Jim T7 Mary T5
Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur.  Project risks affect schedule or resources  Product risks affect the quality or performance of the software being developed  Business risks affect the organisation developing or procuring the software
Software risks Risk Risk type Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule. Requirements change Project and There will be a larger number of product changes to the requirements than anticipated. Specification delays Project and Specifications of essential interfaces product are not available on schedule Size underestimate Project and The size of the system has been product underestimated. CASE tool under- Product CASE tools which support the performance project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed.
The Risk Management Process • Risk identification – Identify project, product and business risks • Risk analysis – Assess the likelihood and consequences of these risks • Risk planning – Draw up plans to avoid or minimise the effects of the risk • Risk monitoring – Monitor the risks throughout the project
The risk management process Risk Risk analysis Risk planning Risk identification monitoring List of potential Risk avoidance Risk Prioritised risk and contingency risks list assessment plans
Risk identification • Technology risks • People risks • Organisational risks • Requirements risks • Estimation risks
Risks and risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Requirements Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
Risk analysis • Assess probability and seriousness of each risk • Probability may be – very low – low – moderate – high or very high • Risk effects might be – catastrophic – serious – Tolerable – insignificant
Risk analysis Risk Probability Effects Organisational financial problems force reductions Low Catastrophic in the project budget. It is impossible to recruit staff with the skills High Catastrophic required for the project. Key staff are ill at critical times in the project. Moderate Serious Software components which should be reused Moderate Serious contain defects which limit their functionality. Changes to requirements which require major Moderate Serious design rework are proposed. The organisation is restructured so that different High Serious management are responsible for the project. The database used in the system cannot process as Moderate Serious many transactions per second as expected. The time required to develop the software is High Serious underestimated. CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant
Risk planning Consider each risk and develop a strategy to manage that risk Avoidance strategies  The probability that the risk will arise is reduced Minimisation strategies  The impact of the risk on the project or product will be reduced Contingency plans  If the risk arises, contingency plans are plans to deal with that risk
Risk management strategies Risk Strategy Organisational Prepare a briefing document for senior management showing financial problems how the project is making a very important contribution to the goals of the business. Recruitment Alert customer of potential difficulties and the possibility of problems delays, investigate buying-in components. Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs. Defective Replace potentially defective components with bought-in components components of known reliability. Requirements Derive traceability information to assess requirements change changes impact, maximise information hiding in the design. Organisational Prepare a briefing document for senior management showing restructuring how the project is making a very important contribution to the goals of the business. Database Investigate the possibilit y of buying a higher-performance performance database. Underestimated Investigate buying in components, investigate use of a program development time generator.
Risk monitoring • Assess each identified risks regularly to decide whether or not it is becoming less or more probable • Also assess whether the effects of the risk have changed • Each key risk should be discussed at management progress meetings
Risk factors Risk type Potential indicators Technology Late delivery of hardware or support software, many reported technology problems People Poor staff morale, poor relationships amongst team member, job availability Organisational organisational gossip, lack of action by senior management Tools reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations Requirements many requirements change requests, customer complaints Estimation failure to meet agreed schedule, failure to clear reported defects
Key points  Good project management is essential for project success.  The intangible nature of software causes problems for management.  Managers have diverse roles but their most significant activities are planning, estimating and scheduling.  Planning and estimating are iterative processes which continue throughout the course of a project.
Key points • A project milestone is a predictable state where some formal report of progress is presented to management. • Risks may be project risks, product risks or business risks • Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats

More Related Content

PDF
Software requirements
Dr. Loganathan R
 
PPT
Lecture1 (SE Introduction)
Education Front
 
PPTX
Requirements engineering
Syed Zaid Irshad
 
PPTX
Software requirement engineering
Syed Zaid Irshad
 
PPTX
Software Engineering- Requirement Elicitation and Specification
Nishu Rastogi
 
PDF
Requirement engineering process
Dr. Loganathan R
 
PDF
Requirements Engineering
Benoy Ramachandran
 
PDF
Requirement Engineering
Jonathan Christian
 
Software requirements
Dr. Loganathan R
 
Lecture1 (SE Introduction)
Education Front
 
Requirements engineering
Syed Zaid Irshad
 
Software requirement engineering
Syed Zaid Irshad
 
Software Engineering- Requirement Elicitation and Specification
Nishu Rastogi
 
Requirement engineering process
Dr. Loganathan R
 
Requirements Engineering
Benoy Ramachandran
 
Requirement Engineering
Jonathan Christian
 

What's hot (20)

PPT
Requirement Engineering
Slideshare
 
PPTX
Design for non functional requirements
Habeeb Mahaboob
 
PPT
Intoduction to software engineering part 1
Rupesh Vaishnav
 
PPT
requirement engineering
anam singla
 
PDF
Software Engineering - Ch7
Siddharth Ayer
 
PPT
Requirement Engineering
University of Haripur
 
DOC
SOFTWARE ENGINEERING
Mahalakshmi Seenaswamy
 
PPTX
Requirement engineering evaluation
Ishraq Al Fataftah
 
PPT
Software requirements engineering lecture 01
Abdul Basit
 
PPTX
Req specification
abdullah229162
 
PPTX
Requirements engineering
Ayaz Shariff
 
PPT
Intoduction to software engineering part 2
Rupesh Vaishnav
 
PPTX
Software Requirements
Nethan Shaik
 
PPTX
Requirements engineering activities
Syed Zaid Irshad
 
PPTX
Requirements Engineering Processes
Ra'Fat Al-Msie'deen
 
PPTX
04 fse understandingrequirements
Mohesh Chandran
 
PPTX
Software requirement enginering
Wajid Ali
 
PPTX
sdlc.pptx
XylemSolutions
 
PPTX
Software Requirement Specification
Niraj Kumar
 
ODP
Visualizing non-functional requirements
Neil Ernst
 
Requirement Engineering
Slideshare
 
Design for non functional requirements
Habeeb Mahaboob
 
Intoduction to software engineering part 1
Rupesh Vaishnav
 
requirement engineering
anam singla
 
Software Engineering - Ch7
Siddharth Ayer
 
Requirement Engineering
University of Haripur
 
SOFTWARE ENGINEERING
Mahalakshmi Seenaswamy
 
Requirement engineering evaluation
Ishraq Al Fataftah
 
Software requirements engineering lecture 01
Abdul Basit
 
Req specification
abdullah229162
 
Requirements engineering
Ayaz Shariff
 
Intoduction to software engineering part 2
Rupesh Vaishnav
 
Software Requirements
Nethan Shaik
 
Requirements engineering activities
Syed Zaid Irshad
 
Requirements Engineering Processes
Ra'Fat Al-Msie'deen
 
04 fse understandingrequirements
Mohesh Chandran
 
Software requirement enginering
Wajid Ali
 
sdlc.pptx
XylemSolutions
 
Software Requirement Specification
Niraj Kumar
 
Visualizing non-functional requirements
Neil Ernst
 
Ad

Viewers also liked (18)

PDF
Mse august13 (2/3)
IIITA
 
PDF
Images
SBC LLC
 
PPTX
Middletown and butler county port authority economic development strategy 201...
SBC LLC
 
PPTX
Improve Your Presentation Skills and Techniques 2016
SBC LLC
 
PPTX
Mountain and Coastal Pines
SBC LLC
 
PPT
Spikes nad SCRUM_Se lect6 btech
IIITA
 
PPTX
Butler county port authority 2011
SBC LLC
 
PPTX
Local government innovation fund
SBC LLC
 
PPTX
Port authority financing for the future one
SBC LLC
 
PPTX
Center for Innovation and Entrepreneurship at UNCW
SBC LLC
 
PPT
JAVA GUI
IIITA
 
PPT
Software Requirements_Se lect8 btech
IIITA
 
PPT
Twelve practices of XP_Se lect5 btech
IIITA
 
PPTX
5 ways to improve your presentation
SBC LLC
 
PPTX
Butler county commissioners office and fiber 10 a1 management improvements in...
SBC LLC
 
PPT
Software Evolution_Se lect3 btech
IIITA
 
PPT
Se lect12 btech
IIITA
 
PPTX
Bcrf 2014 one
SBC LLC
 
Mse august13 (2/3)
IIITA
 
Images
SBC LLC
 
Middletown and butler county port authority economic development strategy 201...
SBC LLC
 
Improve Your Presentation Skills and Techniques 2016
SBC LLC
 
Mountain and Coastal Pines
SBC LLC
 
Spikes nad SCRUM_Se lect6 btech
IIITA
 
Butler county port authority 2011
SBC LLC
 
Local government innovation fund
SBC LLC
 
Port authority financing for the future one
SBC LLC
 
Center for Innovation and Entrepreneurship at UNCW
SBC LLC
 
JAVA GUI
IIITA
 
Software Requirements_Se lect8 btech
IIITA
 
Twelve practices of XP_Se lect5 btech
IIITA
 
5 ways to improve your presentation
SBC LLC
 
Butler county commissioners office and fiber 10 a1 management improvements in...
SBC LLC
 
Software Evolution_Se lect3 btech
IIITA
 
Se lect12 btech
IIITA
 
Bcrf 2014 one
SBC LLC
 
Ad

Similar to Se lect11 btech (20)

PPTX
Software Engineering Unit 2 AKTU Complete
malviyamishra19
 
PPSX
Scope of software engineering
Muhammad Naveed Zafar
 
PDF
Software systems engineering PRINCIPLES
Ivano Malavolta
 
PDF
Software Engineering REQUIREMENTS ANALYSIS AND SPECIFICATION
Dr Anuranjan Misra
 
PPT
INTRODUCTION TO SOFTWARE ENGINEERING
Preeti Mishra
 
PPT
Unit 1 importance ofsoftengg_b.tech iii year
Preeti Mishra
 
PPT
Unit 1 introduction tosoftengg_mba tech ii year
Preeti Mishra
 
PPTX
Introduction to Software Engineering
Amity University | FMS - DU | IMT | Stratford University | KKMI International Institute | AIMA | DTU
 
PPTX
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
VanadhiSathyasekar
 
PPTX
Greate Introduction to Software Engineering @ Track IT Academy
Mohamed Shahpoup
 
PPTX
Module 1(Introduction to Software Engineering).pptx
317shreyac
 
PPTX
UNIT 1 - MPP.pptxdfvvnfuvbrrujfvbvndvnbn
rachanahrr123
 
PPT
SF 9_Unit 1.ppt software engineering ppt
AmarrKannthh
 
PPTX
Software Project Management
ShauryaGupta38
 
PPT
Seminar on Project Management by Rj
Shree M.L.Kakadiya MCA mahila college, Amreli
 
PPTX
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
LeahRachael
 
PPTX
unit 1.pptx regasts sthatbabs shshsbsvsbsh
sagarjsicg
 
PDF
Software_Engineering_in_6_Hours_lyst1728638742594.pdf
VanshMunjal7
 
PDF
Software Engineering in 6 hours of knowledge gate
abhinav23479
 
PPTX
ppt_se.bdfhrfykjyftiktgdukhydiyiuoyu8otrfu
tubashaikh26
 
Software Engineering Unit 2 AKTU Complete
malviyamishra19
 
Scope of software engineering
Muhammad Naveed Zafar
 
Software systems engineering PRINCIPLES
Ivano Malavolta
 
Software Engineering REQUIREMENTS ANALYSIS AND SPECIFICATION
Dr Anuranjan Misra
 
INTRODUCTION TO SOFTWARE ENGINEERING
Preeti Mishra
 
Unit 1 importance ofsoftengg_b.tech iii year
Preeti Mishra
 
Unit 1 introduction tosoftengg_mba tech ii year
Preeti Mishra
 
Introduction to Software Engineering
Amity University | FMS - DU | IMT | Stratford University | KKMI International Institute | AIMA | DTU
 
SOFTWARE ENGINEERING FOR BCA DEGREE STUDENTS
VanadhiSathyasekar
 
Greate Introduction to Software Engineering @ Track IT Academy
Mohamed Shahpoup
 
Module 1(Introduction to Software Engineering).pptx
317shreyac
 
UNIT 1 - MPP.pptxdfvvnfuvbrrujfvbvndvnbn
rachanahrr123
 
SF 9_Unit 1.ppt software engineering ppt
AmarrKannthh
 
Software Project Management
ShauryaGupta38
 
Seminar on Project Management by Rj
Shree M.L.Kakadiya MCA mahila college, Amreli
 
UNIT 1-IDENTIFY THE NEED FOR SOFTWARE ENGINEERING DEVELOPMENT.pptx
LeahRachael
 
unit 1.pptx regasts sthatbabs shshsbsvsbsh
sagarjsicg
 
Software_Engineering_in_6_Hours_lyst1728638742594.pdf
VanshMunjal7
 
Software Engineering in 6 hours of knowledge gate
abhinav23479
 
ppt_se.bdfhrfykjyftiktgdukhydiyiuoyu8otrfu
tubashaikh26
 

Recently uploaded (20)

PPTX
CARE OF UNCONSCIOUS PATIENTS .pptx
AneetaSharma15
 
PPTX
Kanban Cards _ Mass Action in Odoo 18.2 - Odoo Slides
Celine George
 
PPTX
Virus sequence retrieval from NCBI database
yamunaK13
 
PDF
The-Invisible-Living-World-Beyond-Our-Naked-Eye chapter 2.pdf/8th science cur...
Sandeep Swamy
 
PPTX
Tips Management in Odoo 18 POS - Odoo Slides
Celine George
 
DOCX
pgdei-UNIT -V Neurological Disorders & developmental disabilities
JELLA VISHNU DURGA PRASAD
 
PPTX
Artificial-Intelligence-in-Drug-Discovery by R D Jawarkar.pptx
Rahul Jawarkar
 
PPTX
How to Close Subscription in Odoo 18 - Odoo Slides
Celine George
 
PPTX
Introduction to pediatric nursing in 5th Sem..pptx
AneetaSharma15
 
PDF
Module 2: Public Health History [Tutorial Slides]
JonathanHallett4
 
PPTX
Artificial Intelligence in Gastroentrology: Advancements and Future Presprec...
AyanHossain
 
PDF
Virat Kohli- the Pride of Indian cricket
kushpar147
 
PDF
BÀI TẬP TEST BỔ TRỢ THEO TỪNG CHỦ ĐỀ CỦA TỪNG UNIT KÈM BÀI TẬP NGHE - TIẾNG A...
Nguyen Thanh Tu Collection
 
PPTX
HEALTH CARE DELIVERY SYSTEM - UNIT 2 - GNM 3RD YEAR.pptx
Priyanshu Anand
 
PPTX
How to Manage Leads in Odoo 18 CRM - Odoo Slides
Celine George
 
PPTX
Applications of matrices In Real Life_20250724_091307_0000.pptx
gehlotkrish03
 
PPTX
Gupta Art & Architecture Temple and Sculptures.pptx
Virag Sontakke
 
DOCX
SAROCES Action-Plan FOR ARAL PROGRAM IN DEPED
Levenmartlacuna1
 
PPTX
INTESTINALPARASITES OR WORM INFESTATIONS.pptx
PRADEEP ABOTHU
 
PPTX
20250924 Navigating the Future: How to tell the difference between an emergen...
McGuinness Institute
 
CARE OF UNCONSCIOUS PATIENTS .pptx
AneetaSharma15
 
Kanban Cards _ Mass Action in Odoo 18.2 - Odoo Slides
Celine George
 
Virus sequence retrieval from NCBI database
yamunaK13
 
The-Invisible-Living-World-Beyond-Our-Naked-Eye chapter 2.pdf/8th science cur...
Sandeep Swamy
 
Tips Management in Odoo 18 POS - Odoo Slides
Celine George
 
pgdei-UNIT -V Neurological Disorders & developmental disabilities
JELLA VISHNU DURGA PRASAD
 
Artificial-Intelligence-in-Drug-Discovery by R D Jawarkar.pptx
Rahul Jawarkar
 
How to Close Subscription in Odoo 18 - Odoo Slides
Celine George
 
Introduction to pediatric nursing in 5th Sem..pptx
AneetaSharma15
 
Module 2: Public Health History [Tutorial Slides]
JonathanHallett4
 
Artificial Intelligence in Gastroentrology: Advancements and Future Presprec...
AyanHossain
 
Virat Kohli- the Pride of Indian cricket
kushpar147
 
BÀI TẬP TEST BỔ TRỢ THEO TỪNG CHỦ ĐỀ CỦA TỪNG UNIT KÈM BÀI TẬP NGHE - TIẾNG A...
Nguyen Thanh Tu Collection
 
HEALTH CARE DELIVERY SYSTEM - UNIT 2 - GNM 3RD YEAR.pptx
Priyanshu Anand
 
How to Manage Leads in Odoo 18 CRM - Odoo Slides
Celine George
 
Applications of matrices In Real Life_20250724_091307_0000.pptx
gehlotkrish03
 
Gupta Art & Architecture Temple and Sculptures.pptx
Virag Sontakke
 
SAROCES Action-Plan FOR ARAL PROGRAM IN DEPED
Levenmartlacuna1
 
INTESTINALPARASITES OR WORM INFESTATIONS.pptx
PRADEEP ABOTHU
 
20250924 Navigating the Future: How to tell the difference between an emergen...
McGuinness Institute
 

Se lect11 btech

  • 1. IEEE Std 830-1998 Characteristics of a good SRS 1. Correct 6. Verifiable 2. Unambiguous 7. Modifiable 3. Complete 8. Traceable 4. Consistent 5. Ranked for importance and/or stability
  • 2. IEEE Std 830-1998: Parts of an SRS • Introduction – Purpose • purpose of SRS • intended audience for SRS – Scope • identify software to be produced by name • explain what software will (not) do • describe application of software (benefits, objectives)
  • 3. IEEE Std 830-1998: Parts of an SRS • Introduction (continued) – Definitions/acronyms/abbreviations – References • list documents referenced by name and source – Overview • brief description of rest of SRS • organization of SRS
  • 4. IEEE Std 830-1998: Parts of an SRS • Overall description – Product perspective (related products?) • block diagram • constraints – system interfaces » identify functionality that fulfills each system requirement – user interfaces – hardware interfaces – software interfaces » how software interacts with supporting software (purpose, message content and format) » required versions
  • 5. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Product perspective • constraints – communications interfaces » network protocols – memory » requirements/limits on primary and secondary memory – operations » modes of operation » interactive vs. unattended operation » backup & recovery – site adaptation requirement
  • 6. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Product functions • summary of major functions sw will perform – Intended user characteristics • educational level • experience • technical expertise
  • 7. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Constraints (limitations of developer options) • regulatory policies • hardware limitations (e.g. signal timing requirements) • interfaces to other applications • parallel operation • audit functions • control functions • higher-order language requirements • reliability requirements • criticality of the application • safety and security considertations
  • 8. IEEE Std 830-1998: Parts of an SRS • Overall description (continued) – Assumptions and dependencies • e.g. specific OS available on HW – Apportioning of requirements • requirements that may be delayed to future versions
  • 9. IEEE Std 830-1998: Parts of an SRS • Specific requirements – External interfaces – Functions – Performance requirements – Logical database requirements – Design constraints • Standards compliance
  • 10. IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) – Software system attributes • Reliability • Availability • Security • Maintainability • Portability
  • 11. IEEE Std 830-1998: Parts of an SRS • Specific requirements (continued) – Organizing the specific requirements • System mode • User class • Objects • Feature • Stimulus • Response • Functional hierarchy – Additional comments
  • 12. IEEE Std 830-1998: Parts of an SRS • Supporting Information – Table of contents – Index – Appendixes
  • 14. Feasibility Study • A feasibility study is a study made before committing to a project. • A feasibility study leads to a decision: • go ahead • do not go ahead • think again • In production projects, the feasibility study often leads to a budget request. • A feasibility study may be in the form of a proposal.
  • 15. Contents of Feasibility Study Client: Who is this project for? Scope: What are the boundaries of the project? Benefits: What are the benefits? Can they be quantified? Technical: Is the project possible. Is there at least one technical way to carry out the project? Resources: What are the estimates of staff, time, equipment, etc? Alternatives: What are the options if the project is not begun?
  • 16. Feasibility Report A written document • For a general audience: client, financial management, technical management, etc. • Short enough that everybody reads it. • Long enough that no important topics are skipped. • Details are often included in supporting documents. It should be a well written, well presented document.
  • 17. Types of Feasibility • Economic feasibility • Technical feasibility • Operational feasibility • Schedule feasibility • Legal and contractual feasibility • Political feasibility
  • 18. Economic Feasibility • Cost-benefit analysis – identify all the financial benefits and costs associated with a project – Tangible vs. intangible benefits – Tangible vs. intangible costs – One-time vs. recurring costs
  • 19. Technical Feasibility • Assessing the organization’s ability to construct the proposed system • Takes into account various project risk factors
  • 20. Other Feasibility Concerns • Operational – Will the system achieve the objectives of the project? • Schedule – Can the project be accomplished in a reasonable time frame? – Project management critical path scheduling can help answer this concern. • Legal/Contractual – Are there regulations or legal obligations that affect the success of the project? • Political – Will the project have user and management support? – Will there be resistance?
  • 22. What are the Software Project management issues….
  • 23. Software Project management • Software Project Management includes – Planning – Organizing – Monitoring – & Controlling Software Projects.
  • 24. Issues to be handled under SPM
  • 25. Issues to be handled under SPM – People, – Process, – And Problem – Software metrics – Software project – Software process – Software team – Risk
  • 26. Issues to be handled under SPM • How must the – people, – process, – and problem be managed during a software project? • What are software metrics and how can they be used to manage a software project and the software process?
  • 27. Issues to be handled under SPM • How does a software team generate reliable estimates of effort, cost, and project duration? • What techniques can be used to formally assess the risks that can have an impact on project success?
  • 28. Issues to be handled under SPM • How does a software project manager select the set of software engineering work tasks? • How is a project schedule created? • How is quality defined so that it can be controlled? • What is software quality assurance? • Why are formal technical reviews so important? • How is change managed during the development of computer software and after delivery to the customer?
  • 29. Who does Software Project Management
  • 30. Who does Software Project Management • Everyone “manages” to some extent, but the scope of management activities varies with the person doing it. • A software engineer manages his day-to-day activities, planning, monitoring, and controlling technical tasks. • Project managers plan, monitor, and control the work of a team of software engineers. • Senior managers coordinate the interface between the business and the software professionals
  • 32. Why Software Project Management is important • Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time.
  • 34. The 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 34
  • 35. The 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”
  • 36. People management capability maturity model (PM-CMM) • The people management maturity model defines the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development.
  • 37. The 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 identified. • Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress.
  • 38. The Process • A software process provides the framework from which a comprehensive plan for software development can be established. A number of different task sets—tasks, milestones, work products, and quality assurance points—enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.
  • 39. The Project • In 1998, industry data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns. • In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and controlling the project.
  • 40. Who are the Stakeholders in SPM
  • 41. Who are the Stakeholders in SPM • Senior managers who define the business issues that often have significant influence on the project. • Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. • Practitioners who deliver the technical skills that are necessary to engineer a product or application. • Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. • End-users who interact with the software once it is 41 released for production use.
  • 42. What is MOI model of leadership
  • 43. What is MOI model of leadership • Motivation. The ability to encourage (by “push or pull”) 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 final product. • 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.
  • 45. Types of Software Team • Mantei [MAN81] suggests three generic team organizations: • Democratic decentralized (DD). This software engineering team has no permanent leader. Rather, "task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks.“ • Communication within the team is horizontal.
  • 46. Types of Software Team • Controlled decentralized (CD). This software engineering team has a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks. – Problem solving remains a group activity, but implementation of solutions is partitioned among subgroups by the team leader. – Communication among subgroups and individuals is horizontal. Vertical communication along the control hierarchy also occurs.
  • 47. Types of Software Team • Controlled Centralized (CC). Top-level problem solving and internal team coordination are managed by a team leader. Communication between the leader and team members is vertical.
  • 48. What are the Project coordination techniques • Formal, impersonal approaches include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. • Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code inspections.
  • 49. What are the Project coordination techniques • Informal, interpersonal procedures include group meetings for information dissemination and problem solving sessions for development staff. • Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. • Interpersonal networking includes informal discussions with team members and those outside the project who may have experience or insight that can assist team members.
  • 50. Motivation behind the selection of Software Teams
  • 51. Motivation behind the selection of Software Teams • The difficulty of the problem to be solved • The size of the resultant program(s) in lines of code or function points • The time that the team will stay together (team lifetime) • The degree to which the problem can be modularized • The 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 51
  • 52. What is the Product Scope….
  • 53. What is the Product Scope…. • Scope • Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? • Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? • Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed? • Software project scope must be unambiguous and understandable at the management and 53 technical levels.
  • 54. What is Problem Decomposition • Sometimes called partitioning or problem elaboration • Once scope is defined … – It is decomposed into constituent functions – It is decomposed into user-visible data objects or – It is decomposed into a set of problem classes • Decomposition process continues until all functions or problem classes have been defined 54
  • 55. When the Project get into trouble….
  • 56. The Project get into trouble when … • Software people don’t understand their customer’s needs. • The product scope is poorly defined. • Changes are managed poorly. • The chosen technology changes. • Business needs change [or are ill-defined]. • Deadlines are unrealistic. • Users are resistant. • Sponsorship is lost [or was never properly obtained]. • The project team lacks people with appropriate skills. • Managers [and practitioners] avoid best practices and 56 lessons learned.
  • 57. THE W5HH PRINCIPLE: A way of analysis
  • 58. THE W5HH PRINCIPLE: A way of analysis It includes a series of questions that lead to a definition of key project characteristics and the resultant project plan: • Why is the system being developed? • What will be done? • When will it be accomplished? • Who is responsible? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, 58 tools, database) will be needed?
  • 59. Why SPM is different... • The product is intangible. • The product is uniquely flexible. • Software engineering is not recognized as an engineering discipline with the sound status as mechanical, electrical engineering, etc. • The software development process is not standardised. • Many software projects are ‘never-to -be- repeated' projects
  • 61. Types of project plan Plan Description Quality plan Describes the quality procedures and standards that will be used in a project. Validation plan Describes the approach, resources and schedule used for system validation. Configuration Describes the configuration management management plan procedures and structures to be used. Maintenance plan Predicts the maintenance requirements of the system, maintenance costs and effort required. Staff development plan. Describes how the skills and experience of the project team members will be developed.
  • 62. Project plan structure • Introduction • Project organisation • Risk analysis • Hardware and software resource requirements • Work breakdown • Project schedule • Monitoring and reporting mechanisms
  • 64. Activity organization • Activities in a project should be organised to produce tangible outputs for management to judge progress • Milestones are the end-point of a process activity • Deliverables are project results delivered to customers • The waterfall process allows for the straightforward definition of progress milestones
  • 65. Milestones in the SE process
  • 66. Milestones in the SE process ACTIVITIES Feasibility Requir ements Prototype Design Requir ements study analysis development study specification Feasibility Requir ements Evaluation Architectural Requir ements report definition report design specification MILESTONES
  • 68. Project scheduling • Split project into tasks and estimate time and resources required to complete each task • Organize tasks concurrently to make optimal use of workforce • Minimize task dependencies to avoid delays caused by one task waiting for another to complete • Dependent on project managers intuition and experience
  • 69. The project scheduling process Identify Identify activity Estimate resources Allocate people Create project activities dependencies for activities to activities charts Software Activity charts requirements and bar charts
  • 71. Scheduling problems; why it occurs. • Estimating the difficulty of problems and hence the cost of developing a solution is hard • Productivity is not proportional to the number of people working on a task • Adding people to a late project makes it later because of communication overheads • The unexpected always happens. Always allow contingency in planning
  • 72. Bar charts and activity networks • Graphical notations used to illustrate the project schedule • Show project breakdown into tasks. – Tasks should not be too small. – They should take about a week or two • Activity charts show task dependencies and the critical path • Bar charts show schedule against calendar time
  • 73. Task durations and dependencies Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)
  • 74. Activity network 14/7/99 15 days 15 days M1 T3 8 days T9 T1 5 days 4/8/99 25/8/99 25/7/99 T6 M4 M6 4/7/99 M3 start 20 days 7 days 15 days T7 T11 T2 25/7/99 10 days 11/8/99 5/9/99 10 days M2 M7 M8 T4 T5 15 days T10 10 days 18/7/99 T12 M5 25 days T8 Finish 19/9/99
  • 75. Activity timeline 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish
  • 76. Staff allocation 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred T4 T8 T11 T12 Jane T1 T3 T9 Anne T2 T6 T10 Jim T7 Mary T5
  • 77. Risk management Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur.  Project risks affect schedule or resources  Product risks affect the quality or performance of the software being developed  Business risks affect the organisation developing or procuring the software
  • 78. Software risks Risk Risk type Description Staff turnover Project Experienced staff will leave the project before it is finished. Management change Project There will be a change of organisational management with different priorities. Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule. Requirements change Project and There will be a larger number of product changes to the requirements than anticipated. Specification delays Project and Specifications of essential interfaces product are not available on schedule Size underestimate Project and The size of the system has been product underestimated. CASE tool under- Product CASE tools which support the performance project do not perform as anticipated Technology change Business The underlying technology on which the system is built is superseded by new technology. Product competition Business A competitive product is marketed before the system is completed.
  • 79. The Risk Management Process • Risk identification – Identify project, product and business risks • Risk analysis – Assess the likelihood and consequences of these risks • Risk planning – Draw up plans to avoid or minimise the effects of the risk • Risk monitoring – Monitor the risks throughout the project
  • 80. The risk management process Risk Risk analysis Risk planning Risk identification monitoring List of potential Risk avoidance Risk Prioritised risk and contingency risks list assessment plans
  • 81. Risk identification • Technology risks • People risks • Organisational risks • Requirements risks • Estimation risks
  • 82. Risks and risk types Risk type Possible risks Technology The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality. People It is impossible to recruit staff with the skills required. Key staff are ill and unavailable at critical times. Required training for staff is not available. Organisational The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. Tools The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Requirements Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. Estimation The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.
  • 83. Risk analysis • Assess probability and seriousness of each risk • Probability may be – very low – low – moderate – high or very high • Risk effects might be – catastrophic – serious – Tolerable – insignificant
  • 84. Risk analysis Risk Probability Effects Organisational financial problems force reductions Low Catastrophic in the project budget. It is impossible to recruit staff with the skills High Catastrophic required for the project. Key staff are ill at critical times in the project. Moderate Serious Software components which should be reused Moderate Serious contain defects which limit their functionality. Changes to requirements which require major Moderate Serious design rework are proposed. The organisation is restructured so that different High Serious management are responsible for the project. The database used in the system cannot process as Moderate Serious many transactions per second as expected. The time required to develop the software is High Serious underestimated. CASE tools cannot be integrated. High Tolerable Customers fail to understand the impact of Moderate Tolerable requirements changes. Required training for staff is not available. Moderate Tolerable The rate of defect repair is underestimated. Moderate Tolerable The size of the software is underestimated. High Tolerable The code generated by CASE tools is inefficient. Moderate Insignificant
  • 85. Risk planning Consider each risk and develop a strategy to manage that risk Avoidance strategies  The probability that the risk will arise is reduced Minimisation strategies  The impact of the risk on the project or product will be reduced Contingency plans  If the risk arises, contingency plans are plans to deal with that risk
  • 86. Risk management strategies Risk Strategy Organisational Prepare a briefing document for senior management showing financial problems how the project is making a very important contribution to the goals of the business. Recruitment Alert customer of potential difficulties and the possibility of problems delays, investigate buying-in components. Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs. Defective Replace potentially defective components with bought-in components components of known reliability. Requirements Derive traceability information to assess requirements change changes impact, maximise information hiding in the design. Organisational Prepare a briefing document for senior management showing restructuring how the project is making a very important contribution to the goals of the business. Database Investigate the possibilit y of buying a higher-performance performance database. Underestimated Investigate buying in components, investigate use of a program development time generator.
  • 87. Risk monitoring • Assess each identified risks regularly to decide whether or not it is becoming less or more probable • Also assess whether the effects of the risk have changed • Each key risk should be discussed at management progress meetings
  • 88. Risk factors Risk type Potential indicators Technology Late delivery of hardware or support software, many reported technology problems People Poor staff morale, poor relationships amongst team member, job availability Organisational organisational gossip, lack of action by senior management Tools reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations Requirements many requirements change requests, customer complaints Estimation failure to meet agreed schedule, failure to clear reported defects
  • 89. Key points  Good project management is essential for project success.  The intangible nature of software causes problems for management.  Managers have diverse roles but their most significant activities are planning, estimating and scheduling.  Planning and estimating are iterative processes which continue throughout the course of a project.
  • 90. Key points • A project milestone is a predictable state where some formal report of progress is presented to management. • Risks may be project risks, product risks or business risks • Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats