Slides has details about course Software Engineering/ Structured System Analysis and Design.

1. IInnttrroodduuccttiioonn ttoo SSooffttwwaarree
EEnnggiinneeeerriinngg
((UUnniitt 11))
Preeti Mishra
Course Incharge

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

5. Characteristics of a Software

6. Operational Characteristics
• Correctness
• Usability
• Integrity
• Efficiency
• Reliability
• Security
• Safety

7. Revision Characteristics
• Maintainability
• Flexibility
• Extensibility
• Scalability
• Testability
• Moodularity

8. Transitional Characteristics
• Interoperability
• Reusability
• Portability

9. Categories of Computer software
• System software
• Application software
• Engineering/ Scientific software
• Embedded software
• Web-applications
• Artificial intelligence software
• Ubiquitous computing
• Netsourcing

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

20. Project Management
Processes

21. Constraints in Project
Management

22. Generic View of software
Engineering

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.

35. References
• Software Engineering: A practitioner’s
approach
By Roger S. Pressman
• Software Engineering
By Sommerville

36. EEnndd OOff UUnniitt 11