Se lect11 btech

IEEE Std 830-1998 Characteristics of a good SRS

1. Correct

2. Unambiguous

3. Complete

4. Consistent

5. Ranked for importance and/or stability

6. Verifiable

7. Modifiable

8. Traceable

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)


• Introduction (continued)– Definitions/acronyms/abbreviations– References

• list documents referenced by name and source

– Overview• brief description of rest of SRS

• organization of 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


• 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


• 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


• Overall description (continued)– Assumptions and dependencies

• e.g. specific OS available on HW

– Apportioning of requirements• requirements that may be delayed to future versions


• Specific requirements– External interfaces– Functions– Performance requirements– Logical database requirements– Design constraints

• Standards compliance


• Specific requirements (continued)– Software system attributes

• Reliability

• Availability

• Security

• Maintainability

• Portability


• Specific requirements (continued)– Organizing the specific requirements

• System mode

• User class

• Objects

• Feature

• Stimulus

• Response

• Functional hierarchy

– Additional comments


• 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


– 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?


• 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?


• 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 released for production use.

41

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


• 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.


• 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.


• 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.

• 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

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 technical levels.

53

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 lessons learned.

56

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, tools,

database) will be needed?

58

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 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. Configurationmanagement plan

Describes the configuration managementprocedures and structures to be used.

Maintenance plan Predicts the maintenance requirements ofthe system, maintenance costs and effortrequired.

Staff development plan. Describes how the skills and experience ofthe project team members will bedeveloped.

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

Evaluationreport

Prototypedevelopment

Requirementsdefinition

Requirementsanalysis

Feasibilityreport

Feasibilitystudy

Architecturaldesign

Designstudy

Requirementsspecification

Requirementsspecification

ACTIVITIES

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

Estimate resourcesfor activities

Identify activitydependencies

Identifyactivities

Allocate peopleto activities

Create projectcharts

Softwarerequirements

Activity chartsand 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) DependenciesT1 8T2 15T3 15 T1 (M1)T4 10T5 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

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

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

T4

T1T2

M1

T7T3

M5T8

M3

M2T6

T5M4

T9

M7T10

M6

T11M8

T12

Start

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

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

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 risksRisk Risk type DescriptionStaff turnover Project Experienced staff will leave the

project before it is finished.Management change Project There will be a change of

organisational management withdifferent priorities.

Hardware unavailability Project Hardware which is essential for theproject will not be delivered onschedule.

Requirements change Project andproduct

There will be a larger number ofchanges to the requirements thananticipated.

Specification delays Project andproduct

Specifications of essential interfacesare not available on schedule

Size underestimate Project andproduct

The size of the system has beenunderestimated.

CASE tool under-performance

Product CASE tools which support theproject do not perform as anticipated

Technology change Business The underlying technology on whichthe system is built is superseded bynew technology.

Product competition Business A competitive product is marketedbefore 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 avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

Risk identification

• Technology risks

• People risks

• Organisational risks

• Requirements risks

• Estimation risks

Risks and risk types

Risk 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 defectswhich 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 managementare responsible for the project.Organisational financial problems force reductions in the projectbudget.

Tools The code generated by CASE tools is inefficient.CASE tools cannot be integrated.

Requirements Changes to requirements which require major design rework areproposed.Customers fail to understand the impact of requirementschanges.

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 EffectsOrganisational financial problems force reductionsin the project budget.

Low Catastrophic

It is impossible to recruit staff with the skillsrequired for the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate SeriousSoftware components which should be reusedcontain defects which limit their functionality.

Moderate Serious

Changes to requirements which require majordesign rework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

The database used in the system cannot process asmany transactions per second as expected.

Moderate Serious

The time required to develop the software isunderestimated.

High Serious

CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.

Moderate Tolerable

Required training for staff is not available. Moderate TolerableThe rate of defect repair is underestimated. Moderate TolerableThe size of the software is underestimated. High TolerableThe 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 reducedContingency plans

If the risk arises, contingency plans are plans to deal with that risk

Risk management strategies

Risk StrategyOrganisationalfinancial problems

Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.

Recruitmentproblems

Alert customer of potential difficulties and the possibility ofdelays, investigate buying-in components.

Staff illness Reorganise team so that there is more overlap of work andpeople therefore understand each other’s jobs.

Defectivecomponents

Replace potentially defective components with bought-incomponents of known reliability.

Requirementschanges

Derive traceability information to assess requirements changeimpact, maximise information hiding in the design.

Organisationalrestructuring

Prepare a briefing document for senior management showinghow the project is making a very important contribution to thegoals of the business.

Databaseperformance

Investigate the possibility of buying a higher-performancedatabase.

Underestimateddevelopment time

Investigate buying in components, investigate use of a programgenerator.

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 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-poweredworkstations

Requirements many requirements change requests, customercomplaints

Estimation failure to meet agreed schedule, failure to clearreported 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

Education

Se lect11 btech