THE EVOLVING ROLE OF SOFTWARE

Dual Role of Software:

1. As a product –

 It delivers the computing potential across networks of Hardware.

 It enables the Hardware to deliver the expected functionality.
 It acts as an information transformer because it produces, manages, acquires, modifies,
displays, or transmits information.
2. As a vehicle for delivering a product –

 It provides system functionality (e.g., payroll system)

 It controls other software (e.g., an operating system)
 It helps build other software (e.g., software tools)
.

SOFTWARE:- Software is (1) instructions (computer programs) that when executed provide
desired function and performance, (2) Data structures that enable the programs to adequately
manipulate information, and (3) documents that describe the operation and use of the programs.

Software Characteristics:- Software is a logical rather than a physical system element.

Therefore, software has characteristics that are considerably different than those of hardware:
1. Software is developed or engineered; it is not manufactured in the classical sense.
2. Software doesn't "wear out."

3. Although the industry is moving toward component-based assembly, most

Software continues to be custom built.

Software Applications:-

System software. System software is a collection of programs written to service

other programs. Some system software (e.g., compilers, editors, and file management
Utilities) process complex, but determinate, information structures.
Real-time software. Software that monitors/analyzes/controls real-world events
as they occur is called real time. Elements of real-time software include a data gathering
component that collects and formats information from an external environment.
Business software. Business information processing is the largest single software
application area. Discrete "systems" (e.g., payroll, accounts receivable/payable, inventory)
have evolved into management information system (MIS) software that accesses
one or more large databases containing business information.
Engineering and scientific software. Engineering and scientific software have
been characterized by "number crunching" algorithms. Applications range from astronomy
to volcanology, from automotive stress analysis to space shuttle orbital dynamics,
and from molecular biology to automated manufacturing
Embedded software
Embedded software resides in read-only memory and is used to control products and systems for
the consumer and industrial markets.
Embedded software can perform very limited and esoteric functions (e.g., keypad
control for a microwave oven) .
Personal computer software. Word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management, personal and business financial
applications, external network, and database access are only a few of hundreds of
applications.
Web-based software. The Web pages retrieved by a browser are software that
incorporates executable instructions (e.g., CGI, HTML, Perl, or Java), and data (e.g., hypertext
and a variety of visual and audio formats.
Artificial intelligence software. Artificial intelligence (AI) software makes use
of non-numerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis. Expert systems, also called knowledge based
systems, pattern recognition (image and voice), artificial neural networks,
theorem proving, and game playing are representative of applications within this
category.

SOFTWARE MYTHS:-

software myths propagated misinformation and

confusion
Management myths. Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality
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?
Reality: The book of standards may very well exist, but is it used? Are software
practitioners aware of its existence? Does it reflect modern software engineering practice?
Is it complete? Is it streamlined to improve time to delivery while still maintaining
a focus on quality? In many cases, the answer to all of these questions is "no."
Myth: My people have state-of-the-art software development tools, after all, we
buy them the newest computers.
Reality: It takes much more than the latest model mainframe, workstation, or PC
to do high-quality software development. Computer-aided software engineering
(CASE) tools are more important than hardware for achieving good quality and productivity,
yet the majority of software developers still do not use them effectively.
Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
Reality: Software development is not a mechanistic process like manufacturing.
In the words of Brooks "adding people to a late software project makes it later." People can be
added but only in a planned and well-coordinated manner.
Myth: If I decide to outsource3 the software project to a third party, I can just relax
and let that firm build it.
Reality: If an organization does not understand how to manage and control software
projects internally, it will invariably struggle when it outsources software projects.
Customer myths. A customer who requests computer software may be a person
at the next desk, a technical group down the hall, the marketing/sales department,
or an outside company that has requested software under contract.
Myth: A general statement of objectives is sufficient to begin writing programs—
we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts. A
formal and detailed description of the information domain, function, behavior, performance,
interfaces, design constraints, and validation criteria is essential. These
characteristics can be determined only after thorough communication between customer
and developer.
Myth: Project requirements continually change, but change can be easily accommodated
because software is flexible.
Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. If serious attention is given to up-front definition,
early requests for change
can be accommodated easily. The customer can review requirements and recommend
modifications with relatively little impact on cost. When changes are requested
during software design, the cost impact grows rapidly. Resources have been committed
and a design framework has been established.
Practitioner's myths. Myths that are still believed by software practitioners are:
Myth: Once we write the program and get it to work, our job is done.
Reality: Someone once said that "the sooner you begin 'writing code', the longer
it'll take you to get done." Industry data indicate that
between 60 and 80 percent of all effort expended on software will be expended after
it is delivered to the customer for the first time.
Myth: Until I get the program "running" I have no way of assessing its quality.
Reality: One of the most effective software quality assurance mechanisms can be
applied from the inception of a project—the formal technical review. Software reviews
(described in Chapter 8) are a "quality filter" that have been found to be more effective
than testing for finding certain classes of software defects.
Myth: The only deliverable work product for a successful project is the working
program.
Reality: A working program is only one part of a software configuration that includes
many elements. Documentation provides a foundation for successful engineering
and, more important, guidance for software support.
Myth: Software engineering will make us create voluminous and unnecessary documentation
and will invariably slow us down.
Reality: Software engineering is not about creating documents. It is about creating
quality. Better quality leads to reduced rework. And reduced rework results in
faster delivery times.

SOFTWARE ENGINEERING: A LAYERED TECHNOLOGY

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.

Process, Methods, and Tools:- Software engineering is a layered technology.

A Quality Focus:- Total quality management and similar philosophies foster a continuous
process improvement culture, and this culture ultimately leads to the development of
increasingly more mature approaches to software engineering. The bedrock that supports
software engineering is a quality focus.
Process:- The foundation for software engineering is the process layer. 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 for a set
of key process areas (KPAs)that must be established for effective delivery of
software engineering technology. The key process areas form the basis for management
control of software projects and establish the context in which technical methods
are applied, work products (models, documents, data, reports, forms, etc.)
Methods:- Software engineering methods provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis,
design, 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. CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware.

A Generic View of Software Engineering:- The work associated with software engineering
can be categorized into three
generic phases, regardless of application area, project size, or complexity.
Definition phase focuses on what. That is, during definition, the software engineer
attempts to identify what information is to be processed
The development phase focuses on how. That is, during development a software
engineer attempts to define how data are to be structured.
The support phase focuses on change associated with error correction, adaptations
required as the software's environment evolves, and changes due to enhancements
brought about by changing customer requirements.

THE SOFTWARE PROCESS

A software process can be characterized as set of activities performed in software project development.
A common process framework is established by defining a small number of framework activities that are
Applicable to all software projects, regardless of their size or complexity.

A process framework for software engineering defines five framework activities. Framework
activities include communication, planning, modeling, construction and deployment. Each
framework activity includes a set of engineering actions and each action defines a set of tasks
that incorporates work products, project milestones and software quality assurance (SQA) points
that are required.

Umbrella activities
Activities that occur throughout software process for better management and tracking of the
project.
Software project tracking and control – Compare the progress of the project with the plan and
take steps to maintain a planned schedule.
Risk management – Evaluate risks that can affect the outcome and quality of the software
product.
Software quality assurance (SQA) – Conduct activities to ensure the quality of the product.
Technical reviews – Assessment of errors and correction done at each stage of activity.
Measurement – All the measurements of the project and product features.
Software configuration management (SCM) – Controlling and tracking changes in the
software.
Reusability management – Back up work products for reuse and apply the mechanism to
achieve reusable software components.
Work product preparation and production – Project planning and other activities used to
create work product are documented.
 Defining a framework activity
Consider communication activity. For small project, this can be defined as having tasks set:
Making a phone call with stakeholder.
 Discuss requirements and note them down.
 Organize requirements.
 Mail stakeholder for review and approval.
Identifying a task set
Task set is the actual work to be done to achieve an objective of engineering action. For small

project, consider elicitation action in communication activity, this may include:

 Prepare a list of stakeholders of the project.

 Organize a meeting for stakeholders.
 Discuss requirements.
 Finalize requirements list.
 Make a list of issues raised.
Process patterns
Process patterns are patterns used to describe problems and their solutions in the context of software
process. Problems can arise at different levels such as :
Problems associated with a complete process model
Within a framework activity
Within an action in an activity
Patterns can be described using a pattern template which include :
 Pattern name
 Intent (describes process pattern in one or two paragraphs)
 Forces and Types (environment in which problem is encountered is identified and the type of
pattern is specified)
o Stage pattern – explains problems related to framework activity and it may include
multiple task patterns as well.
Example: ‘Establishing Communication’ (stage pattern) includes ‘Requirements
Gathering'(task pattern)
o Task pattern – describes problems related to software engineering action or task such as
Requirements Gathering.
o Phase pattern – defines a sequence of framework activities and ensures each section in the
activity is addressed correctly such as in prototyping, spiral model etc.
 Initial context – Situation to which the pattern is applied. Defines work done so far before the
pattern is applied. Actions and activities that have taken place before the pattern is introduced.
 Problem – Specific problem that is to be solved by the pattern.
 Solution – Implements pattern and initial context is modified to resolve the problem.
 Resulting context – Situation which will result from carrying out the process pattern solution.
 Related patterns – A list of patterns related to the current one is documented for further
reference.