SlideShare a Scribd company logo
1 of 20
Conventional
software
management
Dr Meena Malik(meenamlk@gmail.com)
Conventional software management practices are
• sound in theory, but practically bound to outdated technology and
techniques.
• provides a benchmark of performance for conventional software
management principles.
For Software :
• The best thing is its flexibility as it can be programmed to do
any task.
• The worst thing is also its flexibility, as it very difficult to plan,
monitors, and control software development.
ANALYSES FOR SOFTWARE
ENGINEERING INDUSTRY’S STATE
SAYS
1. Software development is highly
unpredictable as Only about 10% of
software projects are delivered
successfully.
2. Management discipline is more of a
discriminator in success or failure than are
technology advances.
3. The level of software scrap and rework is
indicative of an immature process.
So we can easily state :
a) The success rate for software projects is very low.
b) The three analyses provide a good introduction to the magnitude of
the software problem and the current norms for conventional software
management performance.
THE WATERFALL MODEL
(CONVENTIONAL SOFTWARE
PROCESS)
THEORY perspective:
Basic steps to building a program:
• Analysis and coding both involve creative work that directly
contributes to the usefulness of the end product.
Analysis
coding
• The basic framework described in the
waterfall model is risky and invites
failure.
• The testing phase that occurs at the
end of the development cycle is the
first event for which timing, storage,
input/output transfers, etc., are
experienced as distinguished from
analyzed.
• The resulting design changes are
likely to be so disruptive that the
software requirements upon which the
design is based are likely violated.
• Either the requirements must be
BASIC STEPS IN DEVELOPING A LARGE-
SCALE PROGRAM
5 NECESSARY IMPROVEMENTS FOR
WATERFALL MODEL
1. Program design comes first.
We can Insert a pilot program design phase between the
software requirements generation phase and the analysis
phase so that the program designer assures that the
software will not fail because of storage, timing, and data
flux.
The program designer must impose on the analyst the
storage, timing, and operational constraints in such a way
that he senses the consequences.
If resources applied are insufficient or operational design
is wrong, it will be recognized at this early stage and the
iteration with requirements and preliminary design can be
redone before final design, coding, and test commences
STEPS FOR IMPLEMENTATION OF
PROGRAM DESIGN
Begin the design process with program designers rather than analysts
or programmers.
Design, define, and allocate the data processing modes even at the risk
of being wrong.
Allocate processing functions, design the database, allocate execution
time, define interfaces and processing modes with the operating system,
describe input and output processing, and define preliminary operating
procedures.
Write an overview document that is understandable, informative, and
current so that every worker on the project can gain an elemental
understanding of the system.
5 NECESSARY IMPROVEMENTS FOR
WATERFALL MODEL
2. Document the design:
The amount of documentation required is more than most of the
programmers, analysts, or program designers are willing to do if left to
their own devices. Why do we need so much documentation?
i. Each designer must communicate with interfacing
ii. designers, managers, and possibly customers.
iii. During early phases, the documentation is the design.
iv. The real monetary value of documentation is to support later
modifications by a separate test team, maintenance team, and
operations personnel who are not software literate.
5 NECESSARY IMPROVEMENTS FOR
WATERFALL MODEL
3 Do it twice:
If a computer program is being developed for the first time,
arrange matters so that the version finally delivered to the
customer for operational deployment is actually the second
version insofar as critical design/operations are concerned.
In the first version, the team must have a special broad
competence where they can quickly sense trouble spots in the
design, model them, model alternatives, forget the straightforward
aspects of the design that aren't worth studying at this early point,
and, finally, arrive at an error-free program.
5 NECESSARY
IMPROVEMENTS FOR
WATERFALL MODEL
4. Plan, control, and monitor testing.
The test phase of project consumes more resources -manpower,
computer time and management judgment and being the greatest
risk phase in terms of cost and schedule.
The test phase include:
(1) employ a team of test specialists who were not responsible for
theoriginal design;
(2) employ visual inspections to spot the obvious errors like dropped
minus signs, missing factors of two, jumps to wrong addresses (do not
use the computer to detect this kind of thing, it is too expensive);
(3) test every logic path;
(4) employ the final checkout on the target computer.
5 NECESSARY IMPROVEMENTS FOR
WATERFALL MODEL
5. Involve the customer. It is important to involve the customer in a
formal way so that he has committed himself at earlier points
before final delivery.
There are three points following requirements definition where the
insight, judgment, and commitment of the customer can bolster
the development effort.
These include:
a preliminary software review
a sequence of "critical software design reviews" during program
design,
a "final software acceptance review".
THE WATERFALL MODEL : IN
PRACTICE
Conventional software management approach is still used by
some software projects and may face below listed issues:
1. Protracted integration and late design breakage.
2. Late risk resolution.
3. Requirements-driven functional decomposition.
4. Adversarial (conflict or opposition) stakeholder relationships.
5. Focus on documents and review meetings.
1. PROTRACTED
INTEGRATION AND LATE
DESIGN BREAKAGE
Use of waterfall model process , represents following development
pattern for progress versus time. Progress is defined as percent coded,
that is, demonstrable in its target form. The following sequence was
common:
Early success via paper designs and thorough (often too thorough)
briefings.
Commitment to code late in the life cycle.
Integration nightmares (unpleasant experience) due to unforeseen
implementation issues and interface ambiguities.
Heavy budget and schedule pressure to get the system working.
Late shoe-homing of no optimal fixes, with no time for redesign.
A very fragile, unmentionable product delivered late.
2. REQUIREMENTS-
DRIVEN FUNCTIONAL
DECOMPOSITION
It depends on specifying requirements completely and
unambiguously before other development activities begin.
All requirements as equally important, and depends on those
requirements remaining constant over the software development life
cycle.
Specification of requirements is a difficult and important part of the
software development process.
In conventional approach the requirements were typically specified
in a functional manner.
Built into the classic waterfall process was the fundamental
assumption that the software itself was decomposed into functions;
requirements were then allocated to the resulting components.
This decomposition was often very different from a decomposition
based on object-oriented design and the use of existing components.
REQUIREMENTS-DRIVEN
APPROACHES: SOFTWARE IS
ORGANIZED AROUND THE
REQUIREMENTS SPECIFICATION
STRUCTURE.
3. ADVERSARIAL STAKEHOLDER
RELATIONSHIPS
In conventional process for adversarial stakeholder relationships,
because of the difficulties of requirements specification and the
exchange of information solely through paper documents that
captured engineering information in ad hoc formats. The following
sequence of events was typical for most contractual software
efforts:
The contractor prepared a draft contract-deliverable document that
captured an intermediate artifact and delivered it to the customer
for approval.
The customer was expected to provide comments (typically within
15 to 30 days).
The contractor incorporated these comments and submitted
(typically within 15 to 30 days) a final version for approval.
This one-shot review process encouraged high levels of sensitivity
on the part of customers and contractors.
4. FOCUS ON DOCUMENTS AND
REVIEW MEETINGS
The conventional process focused on producing various
documents that attempted to describe the software product, with
insufficient focus on producing tangible increments of the
products themselves.
Contractors were driven to produce literally tons of paper to meet
milestones and demonstrate progress to stakeholders, rather than
spend their energy on tasks that would reduce risk and produce
quality software.
The presenters and the audience reviewed the simple things that
they understood rather than the complex and important issues.
Most design reviews therefore resulted in low engineering value
and high cost in terms of the effort and schedule involved in their
preparation and conduct.
CONVENTIONAL SOFTWARE
MANAGEMENT PERFORMANCE
Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective
characterization of the state of software development.
1. Finding and fixing a software problem after delivery costs 100 times more than
finding and fixing the problem in early design phases.
2. You can compress software development schedules 25% of nominal, but no
more.
3. For every $1 you spend on development, you will spend $2 on maintenance.
4. Software development and maintenance costs are primarily a function of the
number of source lines of code.
5. Variations among people account for the biggest differences in software
productivity.
6. The overall ratio of software to hardware costs is still growing. In 1955 it was
15:85; in 1985, 85:15.
7. Only about 15% of software development effort is devoted to programming.
8. Software systems and products typically cost 3 times as much per SLOC as
REFERENCES
Software Project management, Walker Royce, Addison
Wesley, 1998.
https://www.javatpoint.com/software-project-management

More Related Content

What's hot

Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation TechniquesSanthi thi
 
Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering arvind pandey
 
Planning the development process
Planning the development processPlanning the development process
Planning the development processSiva Priya
 
Software project management Improving Team Effectiveness
Software project management Improving Team EffectivenessSoftware project management Improving Team Effectiveness
Software project management Improving Team EffectivenessREHMAT ULLAH
 
software project management
software project managementsoftware project management
software project managementdeep sharma
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factorsNancyBeaulah_R
 
Spm project planning
Spm project planning Spm project planning
Spm project planning Kanchana Devi
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineeringkirupasuchi1996
 
Risk management(software engineering)
Risk management(software engineering)Risk management(software engineering)
Risk management(software engineering)Priya Tomar
 
Architectural structures and views
Architectural structures and viewsArchitectural structures and views
Architectural structures and viewsDr Reeja S R
 
Unit 3 3 architectural design
Unit 3 3 architectural designUnit 3 3 architectural design
Unit 3 3 architectural designHiren Selani
 
Improving of software processes
Improving of software processesImproving of software processes
Improving of software processesREHMAT ULLAH
 
Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9koolkampus
 
Software maintenance Unit5
Software maintenance  Unit5Software maintenance  Unit5
Software maintenance Unit5Mohammad Faizan
 
Organization and team structures
Organization and team structuresOrganization and team structures
Organization and team structuresNur Islam
 

What's hot (20)

Software Metrics
Software MetricsSoftware Metrics
Software Metrics
 
Software Cost Estimation Techniques
Software Cost Estimation TechniquesSoftware Cost Estimation Techniques
Software Cost Estimation Techniques
 
Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering Unit 5- Architectural Design in software engineering
Unit 5- Architectural Design in software engineering
 
Planning the development process
Planning the development processPlanning the development process
Planning the development process
 
Software project management Improving Team Effectiveness
Software project management Improving Team EffectivenessSoftware project management Improving Team Effectiveness
Software project management Improving Team Effectiveness
 
software project management
software project managementsoftware project management
software project management
 
Artifacts
ArtifactsArtifacts
Artifacts
 
Chapter 1 2 - some size factors
Chapter 1   2 - some size factorsChapter 1   2 - some size factors
Chapter 1 2 - some size factors
 
Spm project planning
Spm project planning Spm project planning
Spm project planning
 
Designing Techniques in Software Engineering
Designing Techniques in Software EngineeringDesigning Techniques in Software Engineering
Designing Techniques in Software Engineering
 
Staffing level estimation
Staffing level estimation Staffing level estimation
Staffing level estimation
 
Risk management(software engineering)
Risk management(software engineering)Risk management(software engineering)
Risk management(software engineering)
 
Architectural structures and views
Architectural structures and viewsArchitectural structures and views
Architectural structures and views
 
Agile software development
Agile software developmentAgile software development
Agile software development
 
Unit 3 3 architectural design
Unit 3 3 architectural designUnit 3 3 architectural design
Unit 3 3 architectural design
 
Improving of software processes
Improving of software processesImproving of software processes
Improving of software processes
 
Software quality
Software qualitySoftware quality
Software quality
 
Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
 
Software maintenance Unit5
Software maintenance  Unit5Software maintenance  Unit5
Software maintenance Unit5
 
Organization and team structures
Organization and team structuresOrganization and team structures
Organization and team structures
 

Similar to Lect2 conventional software management

Conventional software Management---.pptx
Conventional software Management---.pptxConventional software Management---.pptx
Conventional software Management---.pptxTONY562
 
Software Project Management
Software Project ManagementSoftware Project Management
Software Project ManagementRamesh Babu
 
Pm soln9416141129710
Pm soln9416141129710Pm soln9416141129710
Pm soln9416141129710Nikhil Todkar
 
Fromscrumtokanbantowardlean
FromscrumtokanbantowardleanFromscrumtokanbantowardlean
FromscrumtokanbantowardleanLuca Aliberti
 
Lesson 8...Question Part 2
Lesson 8...Question Part 2Lesson 8...Question Part 2
Lesson 8...Question Part 2bhushan Nehete
 
SoftwareEngineering.pptx
SoftwareEngineering.pptxSoftwareEngineering.pptx
SoftwareEngineering.pptxpriyaaresearch
 
Introduction Software and Software Engineering
Introduction Software and Software EngineeringIntroduction Software and Software Engineering
Introduction Software and Software Engineeringinfinitetechnology20
 
Defect effort prediction models in software maintenance projects
Defect  effort prediction models in software maintenance projectsDefect  effort prediction models in software maintenance projects
Defect effort prediction models in software maintenance projectsiaemedu
 
Lect3 conventional vs modern spm
Lect3 conventional vs modern spmLect3 conventional vs modern spm
Lect3 conventional vs modern spmmeena466141
 
Software Engineering Practices and Issues.pptx
Software Engineering Practices and Issues.pptxSoftware Engineering Practices and Issues.pptx
Software Engineering Practices and Issues.pptxNikilesh8
 
Introduction To Software Engineering
 Introduction To Software Engineering Introduction To Software Engineering
Introduction To Software EngineeringMohsinAli773
 
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...ijseajournal
 
Software Engineering Basics.pdf
Software Engineering Basics.pdfSoftware Engineering Basics.pdf
Software Engineering Basics.pdfPriyajit Sen
 
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005pbaxter
 
61f4fc87-9977-4003-baf8-37f13200977b.pptx
61f4fc87-9977-4003-baf8-37f13200977b.pptx61f4fc87-9977-4003-baf8-37f13200977b.pptx
61f4fc87-9977-4003-baf8-37f13200977b.pptxSuhleemAhmd
 

Similar to Lect2 conventional software management (20)

Conventional software Management---.pptx
Conventional software Management---.pptxConventional software Management---.pptx
Conventional software Management---.pptx
 
Software Project Management
Software Project ManagementSoftware Project Management
Software Project Management
 
Pm soln9416141129710
Pm soln9416141129710Pm soln9416141129710
Pm soln9416141129710
 
San se unit
San se unitSan se unit
San se unit
 
Fromscrumtokanbantowardlean
FromscrumtokanbantowardleanFromscrumtokanbantowardlean
Fromscrumtokanbantowardlean
 
The Waterfall Model
The Waterfall ModelThe Waterfall Model
The Waterfall Model
 
Lesson 8...Question Part 2
Lesson 8...Question Part 2Lesson 8...Question Part 2
Lesson 8...Question Part 2
 
SoftwareEngineering.pptx
SoftwareEngineering.pptxSoftwareEngineering.pptx
SoftwareEngineering.pptx
 
SoftwareEngineering.pptx
SoftwareEngineering.pptxSoftwareEngineering.pptx
SoftwareEngineering.pptx
 
Introduction Software and Software Engineering
Introduction Software and Software EngineeringIntroduction Software and Software Engineering
Introduction Software and Software Engineering
 
Defect effort prediction models in software maintenance projects
Defect  effort prediction models in software maintenance projectsDefect  effort prediction models in software maintenance projects
Defect effort prediction models in software maintenance projects
 
Lect3 conventional vs modern spm
Lect3 conventional vs modern spmLect3 conventional vs modern spm
Lect3 conventional vs modern spm
 
Software Engineering Practices and Issues.pptx
Software Engineering Practices and Issues.pptxSoftware Engineering Practices and Issues.pptx
Software Engineering Practices and Issues.pptx
 
Introduction To Software Engineering
 Introduction To Software Engineering Introduction To Software Engineering
Introduction To Software Engineering
 
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...
STRATEGIES TO REDUCE REWORK IN SOFTWARE DEVELOPMENT ON AN ORGANISATION IN MAU...
 
Software Engineering Basics.pdf
Software Engineering Basics.pdfSoftware Engineering Basics.pdf
Software Engineering Basics.pdf
 
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005
Putting-MANAGEMENT-into-Your-Requirements-Management_Dec2005
 
Cost estimation
Cost estimationCost estimation
Cost estimation
 
Software Development Tips
Software Development TipsSoftware Development Tips
Software Development Tips
 
61f4fc87-9977-4003-baf8-37f13200977b.pptx
61f4fc87-9977-4003-baf8-37f13200977b.pptx61f4fc87-9977-4003-baf8-37f13200977b.pptx
61f4fc87-9977-4003-baf8-37f13200977b.pptx
 

More from meena466141

different consensus protocols in blockchian.pptx
different consensus protocols in blockchian.pptxdifferent consensus protocols in blockchian.pptx
different consensus protocols in blockchian.pptxmeena466141
 
Fundametals of Blockchain and basics_L1.pptx
Fundametals of Blockchain and basics_L1.pptxFundametals of Blockchain and basics_L1.pptx
Fundametals of Blockchain and basics_L1.pptxmeena466141
 
PPT FOR EXPLAINING MERKLE tree and SPV.pptx
PPT FOR EXPLAINING MERKLE tree and SPV.pptxPPT FOR EXPLAINING MERKLE tree and SPV.pptx
PPT FOR EXPLAINING MERKLE tree and SPV.pptxmeena466141
 
New Microsoft PowerPoint Presentation.pptx
New Microsoft PowerPoint Presentation.pptxNew Microsoft PowerPoint Presentation.pptx
New Microsoft PowerPoint Presentation.pptxmeena466141
 
Lect6 life cycle phases
Lect6 life cycle phasesLect6 life cycle phases
Lect6 life cycle phasesmeena466141
 
Lect5 improving software economics
Lect5 improving software economicsLect5 improving software economics
Lect5 improving software economicsmeena466141
 
Lect1 intro to software project management
Lect1 intro to software project managementLect1 intro to software project management
Lect1 intro to software project managementmeena466141
 

More from meena466141 (7)

different consensus protocols in blockchian.pptx
different consensus protocols in blockchian.pptxdifferent consensus protocols in blockchian.pptx
different consensus protocols in blockchian.pptx
 
Fundametals of Blockchain and basics_L1.pptx
Fundametals of Blockchain and basics_L1.pptxFundametals of Blockchain and basics_L1.pptx
Fundametals of Blockchain and basics_L1.pptx
 
PPT FOR EXPLAINING MERKLE tree and SPV.pptx
PPT FOR EXPLAINING MERKLE tree and SPV.pptxPPT FOR EXPLAINING MERKLE tree and SPV.pptx
PPT FOR EXPLAINING MERKLE tree and SPV.pptx
 
New Microsoft PowerPoint Presentation.pptx
New Microsoft PowerPoint Presentation.pptxNew Microsoft PowerPoint Presentation.pptx
New Microsoft PowerPoint Presentation.pptx
 
Lect6 life cycle phases
Lect6 life cycle phasesLect6 life cycle phases
Lect6 life cycle phases
 
Lect5 improving software economics
Lect5 improving software economicsLect5 improving software economics
Lect5 improving software economics
 
Lect1 intro to software project management
Lect1 intro to software project managementLect1 intro to software project management
Lect1 intro to software project management
 

Recently uploaded

Katarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School CourseKatarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School Coursebim.edu.pl
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsResearcher Researcher
 
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.ppt
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.pptROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.ppt
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.pptJohnWilliam111370
 
11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdfHafizMudaserAhmad
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating SystemRashmi Bhat
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfBalamuruganV28
 
Robotics Group 10 (Control Schemes) cse.pdf
Robotics Group 10  (Control Schemes) cse.pdfRobotics Group 10  (Control Schemes) cse.pdf
Robotics Group 10 (Control Schemes) cse.pdfsahilsajad201
 
Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating SystemRashmi Bhat
 
List of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfList of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfisabel213075
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfManish Kumar
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdfCaalaaAbdulkerim
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate productionChinnuNinan
 
Main Memory Management in Operating System
Main Memory Management in Operating SystemMain Memory Management in Operating System
Main Memory Management in Operating SystemRashmi Bhat
 
Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Romil Mishra
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleAlluxio, Inc.
 
Ch10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfCh10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfChristianCDAM
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm Systemirfanmechengr
 
Energy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxEnergy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxsiddharthjain2303
 
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONTHE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONjhunlian
 

Recently uploaded (20)

Katarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School CourseKatarzyna Lipka-Sidor - BIM School Course
Katarzyna Lipka-Sidor - BIM School Course
 
Designing pile caps according to ACI 318-19.pptx
Designing pile caps according to ACI 318-19.pptxDesigning pile caps according to ACI 318-19.pptx
Designing pile caps according to ACI 318-19.pptx
 
Novel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending ActuatorsNovel 3D-Printed Soft Linear and Bending Actuators
Novel 3D-Printed Soft Linear and Bending Actuators
 
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.ppt
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.pptROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.ppt
ROBOETHICS-CCS345 ETHICS AND ARTIFICIAL INTELLIGENCE.ppt
 
11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf11. Properties of Liquid Fuels in Energy Engineering.pdf
11. Properties of Liquid Fuels in Energy Engineering.pdf
 
Virtual memory management in Operating System
Virtual memory management in Operating SystemVirtual memory management in Operating System
Virtual memory management in Operating System
 
CS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdfCS 3251 Programming in c all unit notes pdf
CS 3251 Programming in c all unit notes pdf
 
Robotics Group 10 (Control Schemes) cse.pdf
Robotics Group 10  (Control Schemes) cse.pdfRobotics Group 10  (Control Schemes) cse.pdf
Robotics Group 10 (Control Schemes) cse.pdf
 
Input Output Management in Operating System
Input Output Management in Operating SystemInput Output Management in Operating System
Input Output Management in Operating System
 
List of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdfList of Accredited Concrete Batching Plant.pdf
List of Accredited Concrete Batching Plant.pdf
 
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdfModule-1-(Building Acoustics) Noise Control (Unit-3). pdf
Module-1-(Building Acoustics) Noise Control (Unit-3). pdf
 
Research Methodology for Engineering pdf
Research Methodology for Engineering pdfResearch Methodology for Engineering pdf
Research Methodology for Engineering pdf
 
Crushers to screens in aggregate production
Crushers to screens in aggregate productionCrushers to screens in aggregate production
Crushers to screens in aggregate production
 
Main Memory Management in Operating System
Main Memory Management in Operating SystemMain Memory Management in Operating System
Main Memory Management in Operating System
 
Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________Gravity concentration_MI20612MI_________
Gravity concentration_MI20612MI_________
 
Correctly Loading Incremental Data at Scale
Correctly Loading Incremental Data at ScaleCorrectly Loading Incremental Data at Scale
Correctly Loading Incremental Data at Scale
 
Ch10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdfCh10-Global Supply Chain - Cadena de Suministro.pdf
Ch10-Global Supply Chain - Cadena de Suministro.pdf
 
Class 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm SystemClass 1 | NFPA 72 | Overview Fire Alarm System
Class 1 | NFPA 72 | Overview Fire Alarm System
 
Energy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptxEnergy Awareness training ppt for manufacturing process.pptx
Energy Awareness training ppt for manufacturing process.pptx
 
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTIONTHE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
THE SENDAI FRAMEWORK FOR DISASTER RISK REDUCTION
 

Lect2 conventional software management

  • 2. Conventional software management practices are • sound in theory, but practically bound to outdated technology and techniques. • provides a benchmark of performance for conventional software management principles. For Software : • The best thing is its flexibility as it can be programmed to do any task. • The worst thing is also its flexibility, as it very difficult to plan, monitors, and control software development.
  • 3. ANALYSES FOR SOFTWARE ENGINEERING INDUSTRY’S STATE SAYS 1. Software development is highly unpredictable as Only about 10% of software projects are delivered successfully. 2. Management discipline is more of a discriminator in success or failure than are technology advances. 3. The level of software scrap and rework is indicative of an immature process. So we can easily state : a) The success rate for software projects is very low. b) The three analyses provide a good introduction to the magnitude of the software problem and the current norms for conventional software management performance.
  • 4. THE WATERFALL MODEL (CONVENTIONAL SOFTWARE PROCESS) THEORY perspective: Basic steps to building a program: • Analysis and coding both involve creative work that directly contributes to the usefulness of the end product. Analysis coding
  • 5. • The basic framework described in the waterfall model is risky and invites failure. • The testing phase that occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. • The resulting design changes are likely to be so disruptive that the software requirements upon which the design is based are likely violated. • Either the requirements must be BASIC STEPS IN DEVELOPING A LARGE- SCALE PROGRAM
  • 6. 5 NECESSARY IMPROVEMENTS FOR WATERFALL MODEL 1. Program design comes first. We can Insert a pilot program design phase between the software requirements generation phase and the analysis phase so that the program designer assures that the software will not fail because of storage, timing, and data flux. The program designer must impose on the analyst the storage, timing, and operational constraints in such a way that he senses the consequences. If resources applied are insufficient or operational design is wrong, it will be recognized at this early stage and the iteration with requirements and preliminary design can be redone before final design, coding, and test commences
  • 7. STEPS FOR IMPLEMENTATION OF PROGRAM DESIGN Begin the design process with program designers rather than analysts or programmers. Design, define, and allocate the data processing modes even at the risk of being wrong. Allocate processing functions, design the database, allocate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define preliminary operating procedures. Write an overview document that is understandable, informative, and current so that every worker on the project can gain an elemental understanding of the system.
  • 8. 5 NECESSARY IMPROVEMENTS FOR WATERFALL MODEL 2. Document the design: The amount of documentation required is more than most of the programmers, analysts, or program designers are willing to do if left to their own devices. Why do we need so much documentation? i. Each designer must communicate with interfacing ii. designers, managers, and possibly customers. iii. During early phases, the documentation is the design. iv. The real monetary value of documentation is to support later modifications by a separate test team, maintenance team, and operations personnel who are not software literate.
  • 9. 5 NECESSARY IMPROVEMENTS FOR WATERFALL MODEL 3 Do it twice: If a computer program is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations are concerned. In the first version, the team must have a special broad competence where they can quickly sense trouble spots in the design, model them, model alternatives, forget the straightforward aspects of the design that aren't worth studying at this early point, and, finally, arrive at an error-free program.
  • 10. 5 NECESSARY IMPROVEMENTS FOR WATERFALL MODEL 4. Plan, control, and monitor testing. The test phase of project consumes more resources -manpower, computer time and management judgment and being the greatest risk phase in terms of cost and schedule. The test phase include: (1) employ a team of test specialists who were not responsible for theoriginal design; (2) employ visual inspections to spot the obvious errors like dropped minus signs, missing factors of two, jumps to wrong addresses (do not use the computer to detect this kind of thing, it is too expensive); (3) test every logic path; (4) employ the final checkout on the target computer.
  • 11. 5 NECESSARY IMPROVEMENTS FOR WATERFALL MODEL 5. Involve the customer. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. There are three points following requirements definition where the insight, judgment, and commitment of the customer can bolster the development effort. These include: a preliminary software review a sequence of "critical software design reviews" during program design, a "final software acceptance review".
  • 12. THE WATERFALL MODEL : IN PRACTICE Conventional software management approach is still used by some software projects and may face below listed issues: 1. Protracted integration and late design breakage. 2. Late risk resolution. 3. Requirements-driven functional decomposition. 4. Adversarial (conflict or opposition) stakeholder relationships. 5. Focus on documents and review meetings.
  • 13. 1. PROTRACTED INTEGRATION AND LATE DESIGN BREAKAGE Use of waterfall model process , represents following development pattern for progress versus time. Progress is defined as percent coded, that is, demonstrable in its target form. The following sequence was common: Early success via paper designs and thorough (often too thorough) briefings. Commitment to code late in the life cycle. Integration nightmares (unpleasant experience) due to unforeseen implementation issues and interface ambiguities. Heavy budget and schedule pressure to get the system working. Late shoe-homing of no optimal fixes, with no time for redesign. A very fragile, unmentionable product delivered late.
  • 14.
  • 15. 2. REQUIREMENTS- DRIVEN FUNCTIONAL DECOMPOSITION It depends on specifying requirements completely and unambiguously before other development activities begin. All requirements as equally important, and depends on those requirements remaining constant over the software development life cycle. Specification of requirements is a difficult and important part of the software development process. In conventional approach the requirements were typically specified in a functional manner. Built into the classic waterfall process was the fundamental assumption that the software itself was decomposed into functions; requirements were then allocated to the resulting components. This decomposition was often very different from a decomposition based on object-oriented design and the use of existing components.
  • 16. REQUIREMENTS-DRIVEN APPROACHES: SOFTWARE IS ORGANIZED AROUND THE REQUIREMENTS SPECIFICATION STRUCTURE.
  • 17. 3. ADVERSARIAL STAKEHOLDER RELATIONSHIPS In conventional process for adversarial stakeholder relationships, because of the difficulties of requirements specification and the exchange of information solely through paper documents that captured engineering information in ad hoc formats. The following sequence of events was typical for most contractual software efforts: The contractor prepared a draft contract-deliverable document that captured an intermediate artifact and delivered it to the customer for approval. The customer was expected to provide comments (typically within 15 to 30 days). The contractor incorporated these comments and submitted (typically within 15 to 30 days) a final version for approval. This one-shot review process encouraged high levels of sensitivity on the part of customers and contractors.
  • 18. 4. FOCUS ON DOCUMENTS AND REVIEW MEETINGS The conventional process focused on producing various documents that attempted to describe the software product, with insufficient focus on producing tangible increments of the products themselves. Contractors were driven to produce literally tons of paper to meet milestones and demonstrate progress to stakeholders, rather than spend their energy on tasks that would reduce risk and produce quality software. The presenters and the audience reviewed the simple things that they understood rather than the complex and important issues. Most design reviews therefore resulted in low engineering value and high cost in terms of the effort and schedule involved in their preparation and conduct.
  • 19. CONVENTIONAL SOFTWARE MANAGEMENT PERFORMANCE Barry Boehm's "Industrial Software Metrics Top 10 List” is a good, objective characterization of the state of software development. 1. Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases. 2. You can compress software development schedules 25% of nominal, but no more. 3. For every $1 you spend on development, you will spend $2 on maintenance. 4. Software development and maintenance costs are primarily a function of the number of source lines of code. 5. Variations among people account for the biggest differences in software productivity. 6. The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15. 7. Only about 15% of software development effort is devoted to programming. 8. Software systems and products typically cost 3 times as much per SLOC as
  • 20. REFERENCES Software Project management, Walker Royce, Addison Wesley, 1998. https://www.javatpoint.com/software-project-management