2. The Details
• Software
– Evolving Role
– Characteristics
– Categories and Legacy Softwares
– Software Myths
• Project Management
• Project Estimation
3. Software
• Computer programs or the non
tangible components of computer
• A software is made up of:
• Instruction
• Data Structure
• Documentation
A software is developed or engineered
it is not manufactured
4. Evolving Role of Software
First Era
- Limited distribution
- Batch Oriented
- custom software
Third Era
- Distributed system
- Embedded system
- Consumer impact
Second Era
- Multiuser
- Realtime
- Database
- Product software
Fourth Era
- Powerful desktop PC system
- Object oriented technology
- Artificial Neural Network
- Parallel Computing
10. Legacy Software
• They were developed decades ago and have
been continually modified to meet changes
in business requirements and computing
platforms
• Proliferation of such systems is causing
headaches for large organization- as they
are costly to maintain and risky to evolve
11. Why legacy systems need to
evolve over time??
• To meet needs of new computing
environment
• To implement new business requirements
• To make it interoperable with more
modern systems or databases
• Make it viable within a network
environment
12. Software Myths
• ``Misleading attitudes that have
caused serious problems.'' are
Myths
• A number of common beliefs or
myths that software managers,
customers, and developers believe
falsely.
13. Myths occur at Different Levels
• Software Management Myths
• Software Customer Myths
• Developer Myths
14. Software Management Myths
• Development problems can be solved
by developing and documenting
standards
• Development problems can be solved
by using state-of-the art tools.
• When schedules slip, just add more
people
15. Software Customer Myths
• Change is easily accommodated, since
software is malleable
• A general statement of need is
sufficient to start coding
16. Developer Myths
• The job is done when the code is
delivered
• Project success depends solely on the
quality of the delivered program.
• You can't assess software quality
until the program is running.
17. Software Engineering
• Definition[IEEE] : Software
Engineering: (1) The application of a
systematic, disciplined, quantifiable
approach to the development,
operation, and maintenance of
software; that is, the application of
engineering to software.
18. Project Management
• A project is a :
– temporary endeavour designed to produce a unique
product, service or result
– with a -defined beginning and end,
– undertaken to meet unique goals and objectives,
typically to
– bring about beneficial change or added value.
19. Project Management
• Project management is the process and activity of
– planning,
– organizing,
– motivating,
– controlling
• resources,
• procedures
• protocols
– to achieve specific goals in scientific or daily
problems
23. Definition Phase
In "Definition Phase", the focus is on "What”
• What information is to be processed?
• What performance and
• Functions are required?
• What system behaviour can be expected?
• What interfaces to be established?
• What Design Constraints exists?
• What validation criteria is required?
• What are the key requirements.
24. Development Phase
In "Development Phase", focus is kept on
"How”
• How data are to bt structured?
• How functions are to be implemented?
• How procedural details are to be
implemented?
• How interfaces are to be categorized?
• How design will be translated into
programming languages?
• How testing will be performed?
25. Maintenance Phase
In "Maintenance Phase", the software is
maintained to meet the future
requirements
• Corrective Maintenance
• Adaptive Maintenance
• Perfective Maintenance
• Preventive Maintenance
26. Thus the generic process
framework activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
27. Additional Activities in
Generic Process Model
• Project Tracking and control
• Risk management
• Formal technical review
• Quality assurance
• Measurement
• Configuration management
• Reusability
• Work product preparation and production
28. Project Estimation
• In project management , accurate
estimates are the basis of sound
project planning
• “The single most important task of a
project: setting realistic
expectations
• Unrealistic expectations based on
inaccurate estimates are the single
largest cause of software failure.”
29. Problems with Project
Estimation
• Predicting software cost
• Predicting software schedule
• Controlling software risk
• Managing/tracking project as it
progresses
30. Top-down and bottom-up
estimation
• Top-down
– Start at the system level and assess the
overall system functionality and how this is
delivered through sub-systems.
• Bottom-up
– Start at the component level and estimate
the effort required for each component.
Add these efforts to reach a final estimate.
31. Top-down estimation
– Usable without knowledge of the system
architecture and the components that might be
part of the system.
– Takes into account costs such as integration,
configuration management and documentation.
– Problem:
• Can underestimate the cost of solving difficult low-level
technical problems.
32. Bottom-up estimation
– Usable when the architecture of the system is
known and components identified.
– This can be an accurate method if the system
has been designed in detail.
– Problems:
• It may underestimate the costs of system level
activities such as integration and documentation.
33.
34.
35. References
• Software Engineering: A practitioner’s
approach
By Roger S. Pressman
• Software Engineering
By Sommerville