Software :-

Software is developed or engineered; it is not manufactured in the classical sense

Software doesn’t “wear out.”

Although the industry is moving toward component-based construction, most software continues
to be custom built

Conclusion of realities :-
software in all of its forms and across all of its application domains should be engineered.

definition proposed by Fritz Bauer

Software engineering is the establishment and use of sound engineering principles in order to
obtain economically software that is reliable and works efficiently on real machines

The IEEE has developed a more comprehensive definition when it states: 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. (2) The study of approaches as in (1).

Software engineering is a layered technology.

. The bedrock that supports software engineering is a quality focus. The foundation for software
engineering is the process layer.

Process
➢ The software engineering process is the glue that holds the technology layers together
and enables rational and timely development of computer software.
➢ Process defines a framework that must be established for effective delivery of software
engineering technology.
➢ The software process forms the basis for management control of software projects and
establishes the context in which technical methods are applied, work products are
 produced, milestones are established, quality is ensured, and change is properly
managed.

Methods
➢ Software engineering methods provide the technical how-to’s for building software.
➢ Methods encompass a broad array of tasks that include communication, requirements
analysis, design modeling, program construction, testing, and support.
➢ Software engineering methods rely on a set of basic principles that govern each area of
the technology and include modeling activities and other descriptive techniques.

Tools
➢ Software engineering tools provide automated or semi automated support for the
process and the methods.
➢ When tools are integrated so that information created by one tool can be used by
another, a system for the support of software development, called computer-aided
software engineering, is established.

The Software Process

A process is a collection of activities, actions, and tasks that are performed when
some work product is to be created.
An activity strives to achieve a broad objective (e.g communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
An action (e.g., architectural design) encompasses a set of tasks that produce a major
work product (e.g., an architectural design model).
A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.

A process framework establishes the foundation for a complete software engineering

process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity. In addition, the process
framework encompasses a set of umbrella activities that are applicable across the entire
software process. A generic process framework for software engineering encompasses
five activities:

Communication

Planning

Modeling

Construction
 Deployment

Typical umbrella activities include :

Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.

Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.

Software quality assurance—defines and conducts the activities required to ensure

software quality.

Technical reviews—assesses software engineering work products in an effort to

uncover and remove errors before they are propagated to the next activity.

Measurement—defines and collects process, project, and product measures that assist
the team in delivering software that meets stakeholders’ needs; can be used in
conjunction with all other framework and umbrella activities.

Software configuration management—manages the effects of change throughout the

software process.

Reusability management—defines criteria for work product reuse (including software

components) and establishes mechanisms to achieve reusable components.

Work product preparation and production—encompasses the activities required to

create work products such as models, documents, logs, forms, and lists.

Software Engineering Practice

1. Understand the problem (communication and analysis).

• Who has a stake in the solution to the problem? That is, who are the stakeholders?
• What are the unknowns? What data, functions, and features are required to properly solve the
problem?
• Can the problem be compartmentalized? Is it possible to represent smaller problems that may
be easier to understand?
• Can the problem be represented graphically? Can an analysis model be created?

2. Plan a solution (modeling and software design).

• Have you seen similar problems before? Are there patterns that are recognizable in a potential
solution? Is there existing software that implements the data, functions, and features that are
required?
• Has a similar problem been solved? If so, are elements of the solution reusable?
• Can subproblems be defined? If so, are solutions readily apparent for the subproblems?
• Can you represent a solution in a manner that leads to effective implementation?

3. Carry out the plan (code generation).

• Does the solution conform to the plan? Is source code traceable to the design model?
• Is each component part of the solution provably correct? Have the design and code been
reviewed, or better, have correctness proofs been applied to the algorithm?

4. Examine the result for accuracy (testing and quality assurance).

• Is it possible to test each component part of the solution? Has a reasonable testing strategy
been implemented?
• Does the solution produce results that conform to the data, functions, and features that are
required? Has the software been validated against all stakeholder requirements?

General Principles

The First Principle: The Reason It All Exists

to provide value to its users.

The Second Principle: KISS (Keep It Simple, Stupid!)

All design should be as simple as possible, but no simpler

The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project

The Fourth Principle: What You Produce, Others Will Consume

always specify, design, and implement knowing someone else will have to understand
what you are doing.

The Fifth Principle: Be Open to the Future

Never design yourself into a corner.

The Sixth Principle: Plan Ahead for Reuse

Planning ahead for reuse reduces the cost and increases the value of both the reusable
components and the systems into which they are incorporated.

The Seventh principle: Think!

Placing clear, complete thought before action almost always produces better results.
Myths

Management Myths

Myth: We already have a book that’s full of standards and procedures for building software.
Won’t that provide my people with everything they need to know?

Myth: If we get behind schedule, we can add more programmers and catch up (sometimes
called the “Mongolian horde” concept).

Myth: If I decide to outsource the software project to a third party, I can just relax and let that
firm build it.

Customer Myths

Myth: A general statement of objectives is sufficient to begin writing programs—we can fill in the
details later.

Myth: Software requirements continually change, but change can be easily accommodated
because software is flexible.

Practitioner’s myths.

Myth: Once we write the program and get it to work, our job is done

Myth: Until I get the program “running” I have no way of assessing its quality.

Myth: The only deliverable work product for a successful project is the working program.

Myth: Software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down.