Types of requirement•   User requirements•   System requirements•   Domain requirements•   Functional requirements•   Non-...
Non-functional requirementtypes                                                     Non-functional                        ...
Requirements measures
Requirements measures   Property      Measure   Speed         Processed transactions/second                 User/Event res...
Relationship & Difference BetweenRequirement and Design
Requirements vs. Design       Requirements                     DesignDescribe what will be       Describe how it will be d...
Requirements and design• In practice,     requirements      and    design    are  inseparable  – A system architecture may...
Relationships between userneeds, concerns and NFRs
Relationships between userneeds, concerns and NFRsUser’s need                User’s concern         Non-functional        ...
How to write requirements:
Guidelines for writing requirements• Invent a standard format and use it for all  requirements• Use language in a consiste...
Problems with natural language
Problems with natural language• Lack of clarity  – Precision is difficult without making the document difficult    to read...
Alternatives to NL specification
Alternatives to NL specification Notation         Description Structured       This approach depends on defining standard ...
What is Requirement Document
The requirements document• The requirements document is the official  statement of what is required of the system  develop...
Users of a requirements document
S e if th r q i e e t a d                  p c y e e u mns n                               r                 r a t e t c e...
Requirements documentrequirements
Requirements documentrequirements• Specify external system behaviour• Specify implementation constraints• Easy to change• ...
Software RequirementsSpecification (SRS) • What is an SRS? • What is the purpose of an SRS?   – Who reads the SRS?   – Who...
What is an SRS?• It is a document that you prepare:  – after customer gives you their system specifications  – before you ...
What is the purpose of an SRS?• “The SRS precisely defines the software product  that will be built.”      [readyset.tigri...
Purpose (continued)1. “It provides feedback to the customer.”2. “It decomposes the problem into component   parts.”3. “It ...
Who reads the SRS?The purpose of an SRS is to communicate with thecustomer:  – The SRS must make clear to the customer whe...
Who reads (continued)The purpose of an SRS is to communicate with thedesigners:  – The SRS must be detailed enough that th...
Who writes the SRS?• Developers  – Architects  – Programmers• Technical writers• Customer may be involved
Basis for User Manual• The SRS can serve as the basis for a User  Manual for the software:  – Use case descriptions in SRS...
IEEE Std 830-1998 Characteristics ofa good SRS1.   Correct             6. Verifiable2.   Unambiguous         7. Modifiable...
IEEE Std 830-1998: Parts of anSRS  • Introduction    – Purpose       • purpose of SRS       • intended audience for SRS   ...
IEEE Std 830-1998: Parts of anSRS   • Introduction (continued)     – Definitions/acronyms/abbreviations     – References  ...
IEEE Std 830-1998: Parts of anSRS• Overall description  – Product perspective (related products?)     • block diagram     ...
IEEE Std 830-1998: Parts of anSRS• Overall description (continued)  – Product perspective     • constraints        – commu...
IEEE Std 830-1998: Parts of an SRS• Overall description (continued)  – Product functions     • summary of major functions ...
IEEE Std 830-1998: Parts of anSRS• Overall description (continued)  – Constraints (limitations of developer options)     •...
IEEE Std 830-1998: Parts of an  SRS• Overall description (continued)  – Assumptions and dependencies     • e.g. specific O...
IEEE Std 830-1998: Parts of an SRS• Specific requirements  –   External interfaces  –   Functions  –   Performance require...
IEEE Std 830-1998: Parts of an    SRS• Specific requirements (continued)  – Software system attributes     •   Reliability...
IEEE Std 830-1998: Parts of an    SRS• Specific requirements (continued)  – Organizing the specific requirements     •   S...
IEEE Std 830-1998: Parts of an    SRS• Supporting Information  – Table of contents  – Index  – Appendixes
Requirements EngineeringRequirements  Definition                 Feasibility                   Study                      ...
Requirements EngineeringRequirements  Definition                 Feasibility                   Study                      ...
Requirements EngineeringRequirements  Definition                 Feasibility                   Study                      ...
Phases of the project lifecycle
Feasibility Study
Feasibility Study• A feasibility study is a study made before  committing to a project.• A feasibility study leads to a de...
Contents of Feasibility Study Client: Who is this project for? Scope: What are the boundaries of the project? Benefits: Wh...
Feasibility ReportA written document• For a general audience: client, financial management,  technical management, etc.•  ...
Types of Feasibility•   Economic feasibility•   Technical feasibility•   Operational feasibility•   Schedule feasibility• ...
Economic Feasibility• Cost-benefit analysis – identify all the financial  benefits and costs associated with a project• Ta...
Technical Feasibility• Assessing the organization’s ability to construct  the proposed system• Takes into account various ...
Other Feasibility Concerns• Operational   – Will the system achieve the objectives of the project?• Schedule   – Can the p...
SOFTWARE PROJECTMANAGEMENT
Software Project management• Software Project Management includes  – Planning  – Organizing  – Monitoring  – & Controlling...
Issues to be handled underSPM• How must the people, process, and problem  be managed during a software project?• What are ...
Issues to be handled under SPM• How does a software project manager select the  set of software engineering work tasks?• H...
Definition of Project Management • Project management involves the   planning, organizing, monitoring, and   control of th...
What is Software projectmanagement• Concerned with activities involved in ensuring  that software is delivered on time and...
Who does Software ProjectManagement• Everyone “manages” to some extent, but the  scope of management activities varies wit...
Why Software Project Management isimportant• Building computer software is a  complex undertaking, particularly if it  inv...
The 4 P’s• People — the most important element of a  successful project• Product — the software to be built• Process — the...
The People • The “people factor” is so important that the   Software Engineering Institute has developed   a people manage...
People management capabilitymaturity model (PM-CMM)• The people management maturity model  defines the following key pract...
The Product• Before a project can be planned, product  objectives and scope should be established.• Alternative solutions ...
The Process• A software process provides the framework  from which a comprehensive plan for software  development can be e...
The Project• In 1998, industry data indicated that 26  percent of software projects failed outright and  46 percent experi...
Who are the Stakeholders in SPM• Senior managers who define the business issues  that often have significant influence on ...
What is MOI model of leadership• Motivation. The ability to encourage (by  “push or pull”) technical people to produce to ...
Types of Software Team• Mantei [MAN81] suggests three generic team  organizations:• Democratic       decentralized  (DD). ...
Types of Software Team• Controlled decentralized (CD). This software  engineering team has a defined leader who  coordinat...
Types of Software Team• Controlled Centralized (CC). Top-level  problem     solving  and   internal  team  coordination ar...
What are the Project coordinationtechniques • Formal, impersonal approaches include   software     engineering     documen...
What are the Project coordinationtechniques • Informal, interpersonal procedures include   group meetings for information ...
Motivation behind the selection ofSoftware Teams• The difficulty of the problem to be solved• The size of the resultant pr...
Types of Organizational Structure     • Closed —structures a team along            a traditional       hierarchy of author...
What is the Product Scope….• Scope     • Context. How does the software to be built fit into a       larger system, produc...
What is Problem Decomposition• Sometimes called partitioning or problem  elaboration• Once scope is defined …  – It is dec...
The Process• Once a process framework has been  established  – Consider project characteristics  – Determine the degree of...
The Project get into troublewhen …• Software people don’t understand their customer’s  needs.• The product scope is poorly...
Common-Sense Approach to Projects•   Start on the right foot.•   Maintain momentum.•   Track progress.•   Make smart decis...
THE W5HH PRINCIPLE: A way ofanalysisIt includes a series of questions that lead to a   definition of key project character...
Why SPM is different... • The product is intangible. • The product is uniquely flexible. • Software engineering is not rec...
What are the Management activities•   Proposal writing•   Project planning and scheduling•   Project costing•   Project mo...
Why Project planning is important• Probably the most time-consuming project  management activity• Continuous activity from...
Types of project planPlan                      DescriptionQuality plan              Describes the quality        procedure...
Project plan structure•   Introduction•   Project organisation•   Risk analysis•   Hardware and software resource requirem...
Activity organization• Activities in a project should be organised to  produce tangible outputs for management to  judge p...
Milestones in the SE process                              ACTIVITIESFeasibility   Requir ements    Prototype      Design  ...
Project scheduling• Split project into tasks and estimate time and  resources required to complete each task• Organize tas...
The project scheduling process  Identify     Identify activity   Estimate resources   Allocate people   Create project act...
Scheduling problems; why itoccurs.• Estimating the difficulty of problems and  hence the cost of developing a solution is ...
Bar charts and activity networks• Graphical notations used to illustrate the  project schedule• Show project breakdown int...
Task durations and dependencies Task    Duration (days)   Dependencies  T1            8  T2           15  T3           15 ...
Activity network                               14/7/99        15 days                                                     ...
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...
Staff allocation       4/7   11/7    18/7     25/   1/8    8/8    15/8 22/8   29/8   5/9     12/9   19/9Fred    T4        ...
Risk managementRisk management is concerned with identifying risks and drawing up plans to minimise their effect on a pro...
Software risks Risk                      Risk type     Description Staff turnover            Project       Experienced sta...
The Risk Management Process• Risk identification  – Identify project, product and business risks• Risk analysis  – Assess ...
The risk management process     Risk           Risk analysis      Risk planning       Risk identification                 ...
Risk identification•   Technology risks•   People risks•   Organisational risks•   Requirements risks•   Estimation risks
Risks and risk typesRisk type        Possible risksTechnology       The database used in the system cannot process as many...
Risk analysis• Assess probability and seriousness of each  risk• Probability may be  –   very low  –   low  –   moderate  ...
Risk analysis    Risk                                                  Probability Effects    Organisational financial pro...
Risk planningConsider each risk and develop a strategy to manage that riskAvoidance strategies   The probability that t...
Risk management strategies  Risk                 Strategy  Organisational       Prepare a briefing document for senior man...
Risk monitoring• Assess each identified risks regularly to  decide whether or not it is becoming less or  more probable• A...
Risk factorsRisk type        Potential indicatorsTechnology       Late delivery of hardware or support software, many     ...
Key points Good project management is essential for project  success. The intangible nature of software causes  problems...
Key points• A project milestone is a predictable state  where  some formal report of progress is presented to  management....
Upcoming SlideShare
Loading in …5
×

Software PROJECT MANAGEMENT_Se lect10 btech

561 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
561
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  •  
  •  
  •  
  • Software PROJECT MANAGEMENT_Se lect10 btech

    1. 1. Types of requirement• User requirements• System requirements• Domain requirements• Functional requirements• Non-functional requirements
    2. 2. Non-functional requirementtypes Non-functional requirements Product Organizational External requirements requirements requirements Efficiency Reliability Portability Interoperability Ethical requirements requirements requirements requirements requirements Usability Delivery Implementation Standards Legislativerequirements requirements requirements requirements requirementsPerformance Space Privacy Safetyrequirements requirements requirements requirements
    3. 3. Requirements measures
    4. 4. Requirements measures Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use T raining time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness T ime to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems
    5. 5. Relationship & Difference BetweenRequirement and Design
    6. 6. Requirements vs. Design Requirements DesignDescribe what will be Describe how it will be donedeliveredPrimary goal of analysis: Primary goal of design:UNDERSTANDING OPTIMIZATIONThere is more than one There is only one (final)solution solutionCustomer interested Customer not interested (Most of the time) except for external
    7. 7. Requirements and design• In practice, requirements and design are inseparable – A system architecture may be designed to structure the requirements – The system may inter-operate with other systems that generate design requirements – The use of a specific design may be a domain requirement
    8. 8. Relationships between userneeds, concerns and NFRs
    9. 9. Relationships between userneeds, concerns and NFRsUser’s need User’s concern Non-functional requirementFunction 1. Ease of use 1. Usability 2. Unauthorised access 2. Security 3. Likelihood of failure 3. ReliabilityPerformance 1. Resource utilisation 1. Efficiency 2. Performance verification 2. 3. Ease of interfacing Verifiability 3. InteroperabilityChange 1. Ease of repair 1. Maintainability 2. Ease of change 2. Flexibility 3. Ease of transport ? 3. Portability 4. Ease of expanding or upgrading 4. Expandability capacity or performance ?
    10. 10. How to write requirements:
    11. 11. Guidelines for writing requirements• Invent a standard format and use it for all requirements• Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements• Use text highlighting to identify key parts of the requirement
    12. 12. Problems with natural language
    13. 13. Problems with natural language• Lack of clarity – Precision is difficult without making the document difficult to read• Requirements confusion – Functional and non-functional requirements tend to be mixed-up• Requirements combination – Several different requirements may be expressed together
    14. 14. Alternatives to NL specification
    15. 15. Alternatives to NL specification Notation Description Structured This approach depends on defining standard natural forms or templates to express the requirements language specification. Design This approach uses a language like a description programming language but with more abstract languages features to specify the requirements by defining an operational model of the system. Graphical A graphical language, supplemented by text notations annotations is used to define the functional requirements for the system. Mathematical These are notations based on mathematical specifications concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality.
    16. 16. What is Requirement Document
    17. 17. The requirements document• The requirements document is the official statement of what is required of the system developers• Should include both a definition and a specification of requirements• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it
    18. 18. Users of a requirements document
    19. 19. S e if th r q i e e t a d p c y e e u mns n r r a t e t c e k a th y e d h mo h c th t eS s m u t mr y te c so e s me t ern e s T e e t h i e d. h y s e i yc a g stot e p cf h n e h r q ie e t e ur mns Ueth r q ir mn s e e u e e ts Mn g r a a es d c mn t p nab f r o u e t o la id o th s se a dt p nt e e y t m n o la h s s m e eo mn p o e s y te d v l p e t r c s Ueth r q ir mn t s e e u e e ts oSs mni ery te e gn e s u d r t n wa s se ist n e sa d h t y t m o b dv l pd e e eo e S s me t y te t s Ueth r q ir mn t s e e u e e ts o e gn e s ni er d v l pv li aio t ssf r e eo a d t n e t o th s se e yt m Users of a Ss m y te Ueth r q ir mn t h lp s e e u e e ts o e requirement u d r t n t es s m n n esa d h y te a d mi t n n e ane a c th r laio s i sb t e ni e e t n hp ewe ts s document e gn e s ni er pr ats
    20. 20. Requirements documentrequirements
    21. 21. Requirements documentrequirements• Specify external system behaviour• Specify implementation constraints• Easy to change• Serve as reference tool for maintenance• Record forethought about the life cycle of the system i.e. predict changes• Characterise responses to unexpected events
    22. 22. Software RequirementsSpecification (SRS) • What is an SRS? • What is the purpose of an SRS? – Who reads the SRS? – Who writes the SRS? • What information is put into an SRS? • What do you need to do for phase 1?
    23. 23. What is an SRS?• It is a document that you prepare: – after customer gives you their system specifications – before you design the system
    24. 24. What is the purpose of an SRS?• “The SRS precisely defines the software product that will be built.” [readyset.tigris.org/nonav/templates/srs.html]• The SRS is your “response to the customer’s System Specification ... and tells a potential customer how you intend to solve their problem.” [CSE442 project description]• “The [SRS] specifies the requirements … and the methods to be used to ensure that each requirement has been met.”
    25. 25. Purpose (continued)1. “It provides feedback to the customer.”2. “It decomposes the problem into component parts.”3. “It serves as an input to the design specification.”4. “It serves as a product validation check.”
    26. 26. Who reads the SRS?The purpose of an SRS is to communicate with thecustomer: – The SRS must make clear to the customer whether you have understood their system specification correctly and completely. SRS is written in plain language (not a formal language).
    27. 27. Who reads (continued)The purpose of an SRS is to communicate with thedesigners: – The SRS must be detailed enough that the designers can construct a design for the system from this document.
    28. 28. Who writes the SRS?• Developers – Architects – Programmers• Technical writers• Customer may be involved
    29. 29. Basis for User Manual• The SRS can serve as the basis for a User Manual for the software: – Use case descriptions in SRS describe required functionality of the system, from the perspective of a user. – This can be extended to become a description of how to carry out these required tasks with the finished system.
    30. 30. IEEE Std 830-1998 Characteristics ofa good SRS1. Correct 6. Verifiable2. Unambiguous 7. Modifiable3. Complete 8. Traceable4. Consistent5. Ranked for importance and/or stability
    31. 31. IEEE Std 830-1998: Parts of anSRS • 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)
    32. 32. IEEE Std 830-1998: Parts of anSRS • Introduction (continued) – Definitions/acronyms/abbreviations – References • list documents referenced by name and source – Overview • brief description of rest of SRS • organization of SRS
    33. 33. IEEE Std 830-1998: Parts of anSRS• 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
    34. 34. IEEE Std 830-1998: Parts of anSRS• 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
    35. 35. 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
    36. 36. IEEE Std 830-1998: Parts of anSRS• 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
    37. 37. 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
    38. 38. IEEE Std 830-1998: Parts of an SRS• Specific requirements – External interfaces – Functions – Performance requirements – Logical database requirements – Design constraints • Standards compliance
    39. 39. IEEE Std 830-1998: Parts of an SRS• Specific requirements (continued) – Software system attributes • Reliability • Availability • Security • Maintainability • Portability
    40. 40. 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
    41. 41. IEEE Std 830-1998: Parts of an SRS• Supporting Information – Table of contents – Index – Appendixes
    42. 42. Requirements EngineeringRequirements Definition Feasibility Study Requirements Elicitation and Feasibility Analysis Report Requirements Specification System Models V&V SRS Requirements *Software Project Definition Management User ManualDocument (RDD) Plan Test Plan
    43. 43. Requirements EngineeringRequirements Definition Feasibility Study Requirements Elicitation and Feasibility Analysis Report Requirements Specification System Models V&V SRS Requirements *Software Project Definition Management User ManualDocument (RDD) Plan Test Plan
    44. 44. Requirements EngineeringRequirements Definition Feasibility Study Requirements Elicitation and Feasibility Analysis Report Requirements Specification System Models V&V SRS Requirements *Software Project Definition Management User ManualDocument (RDD) Plan Test Plan
    45. 45. Phases of the project lifecycle
    46. 46. Feasibility Study
    47. 47. 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.
    48. 48. 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?
    49. 49. Feasibility ReportA 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.
    50. 50. Types of Feasibility• Economic feasibility• Technical feasibility• Operational feasibility• Schedule feasibility• Legal and contractual feasibility• Political feasibility
    51. 51. 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
    52. 52. Technical Feasibility• Assessing the organization’s ability to construct the proposed system• Takes into account various project risk factors
    53. 53. 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?
    54. 54. SOFTWARE PROJECTMANAGEMENT
    55. 55. Software Project management• Software Project Management includes – Planning – Organizing – Monitoring – & Controlling Software Projects.
    56. 56. Issues to be handled underSPM• 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?• 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?
    57. 57. 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?
    58. 58. Definition of Project Management • Project management involves the planning, organizing, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to an operational implementation.
    59. 59. What is Software projectmanagement• Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.• Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.
    60. 60. Who does Software ProjectManagement• 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
    61. 61. Why Software Project Management isimportant• Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time.
    62. 62. 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 62
    63. 63. 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”
    64. 64. People management capabilitymaturity 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.• Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices.
    65. 65. 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.
    66. 66. 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.
    67. 67. 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
    68. 68. 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 68 released for production use.
    69. 69. 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.
    70. 70. 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.“ Decisions on problems and approach are made by group consensus. Communication among team members is horizontal.
    71. 71. 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.
    72. 72. 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.
    73. 73. What are the Project coordinationtechniques • 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
    74. 74. What are the Project coordinationtechniques • 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
    75. 75. Motivation behind the selection ofSoftware 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 75•
    76. 76. Types of Organizational Structure • Closed —structures a team along a traditional hierarchy of authority • Random —structures a team loosely and depends on individual initiative of the team members • Open —attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm • Synchronous —relies on the natural partitioning of a problem and organizes team members to work on pieces of the problem with little active communication among themselves 76suggested by Constantine [CON93]
    77. 77. 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 77 technical levels.
    78. 78. 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 78
    79. 79. The Process• Once a process framework has been established – Consider project characteristics – Determine the degree of rigor required – Define a task set for each software engineering activity • Task set = – Software engineering tasks – Work products – Quality assurance points 79 – Milestones
    80. 80. The Project get into troublewhen …• 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 80 lessons learned.
    81. 81. Common-Sense Approach to Projects• Start on the right foot.• Maintain momentum.• Track progress.• Make smart decisions.• Conduct a postmortem analysis. 81
    82. 82. THE W5HH PRINCIPLE: A way ofanalysisIt 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, 82
    83. 83. 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
    84. 84. What are the Management activities• Proposal writing• Project planning and scheduling• Project costing• Project monitoring and reviews• Personnel selection and evaluation• Report writing and presentations
    85. 85. Why Project planning is important• Probably the most time-consuming project management activity• Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available.• Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget
    86. 86. Types of project planPlan DescriptionQuality 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 managementmanagement 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.
    87. 87. Project plan structure• Introduction• Project organisation• Risk analysis• Hardware and software resource requirements• Work breakdown• Project schedule• Monitoring and reporting mechanisms
    88. 88. 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
    89. 89. Milestones in the SE process ACTIVITIESFeasibility Requir ements Prototype Design Requir ements study analysis development study specificationFeasibility Requir ements Evaluation Architectural Requir ements report definition report design specification MILESTONES
    90. 90. 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
    91. 91. The project scheduling process Identify Identify activity Estimate resources Allocate people Create project activities dependencies for activities to activities charts Software Activity chartsrequirements and bar charts
    92. 92. Scheduling problems; why itoccurs.• 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
    93. 93. 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
    94. 94. 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)
    95. 95. 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
    96. 96. 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
    97. 97. Staff allocation 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9Fred T4 T8 T11 T12Jane T1 T3 T9Anne T2 T6 T10Jim T7Mary T5
    98. 98. 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
    99. 99. 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.
    100. 100. 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
    101. 101. The risk management process Risk Risk analysis Risk planning Risk identification monitoringList of potential Risk avoidance Risk Prioritised risk and contingency risks list assessment plans
    102. 102. Risk identification• Technology risks• People risks• Organisational risks• Requirements risks• Estimation risks
    103. 103. Risks and risk typesRisk type Possible risksTechnology 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.
    104. 104. 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
    105. 105. 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
    106. 106. 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
    107. 107. 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.
    108. 108. 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
    109. 109. Risk factorsRisk type Potential indicatorsTechnology Late delivery of hardware or support software, many reported technology problemsPeople Poor staff morale, poor relationships amongst team member, job availabilityOrganisational organisational gossip, lack of action by senior managementTools reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstationsRequirements many requirements change requests, customer complaintsEstimation failure to meet agreed schedule, failure to clear reported defects
    110. 110. 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.
    111. 111. 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

    ×