Introduction to Software Introduction to Software EngineeringEngineering

(Unit 1)(Unit 1)

Preeti MishraCourse Incharge

The Details• Software

– Evolving Role– Characteristics– Categories and Legacy Softwares– Software Myths

• Project Management• Project Estimation

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

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

Characteristics of a Software

Operational Characteristics

• Correctness• Usability• Integrity• Efficiency• Reliability• Security• Safety

Revision Characteristics

• Maintainability• Flexibility• Extensibility• Scalability• Testability• Moodularity

Transitional Characteristics

• Interoperability• Reusability• Portability

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

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

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

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.

Myths occur at Different Levels

• Software Management Myths• Software Customer Myths• Developer Myths

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

Software Customer Myths

• Change is easily accommodated, since software is malleable

• A general statement of need is sufficient to start coding

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.

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.

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.

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

Project Management Processes

Constraints in Project Management

Generic View of software Engineering

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.

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?

Maintenance Phase

In "Maintenance Phase", the software is maintained to meet  the future requirements

• Corrective Maintenance • Adaptive Maintenance• Perfective Maintenance• Preventive Maintenance

Thus the generic process framework activities

• Communication• Planning• Modeling• Construction• Deployment

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

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

Problems with Project Estimation

• Predicting software cost• Predicting software schedule• Controlling software risk• Managing/tracking project as it

progresses

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.

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.

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.

References

• Software Engineering: A practitioner’s approach

By Roger S. Pressman• Software Engineering

By Sommerville

End Of Unit 1End Of Unit 1