Software Engineering

Software Engineering MCA II
SOFTWARE ENGINEERING
Purbanchal University
MCA II Semester

sarojpandey.com.np 1 of 146

References:
1. Handouts provided by Er. Niraj Man Shrestha. [2005]
2. Sommerville I., Software Engineering, 6th Edition PEA.
3. Pressman R, Software Engineering Practitioners Approach 5th Edition MC GrawHill.
4. Slides from Guest Lectures.

Thanks All!
Syllabus

1. Introduction to Software Engineering 3 Hours
Definition, Scope, Software Products Process, Responsibilities of Software Engineer, Ethical
Issues

2. Software design 8 Hours
Fundamental design concepts and principles, Design patterns, Software architecture, structured
design, Object-oriented analysis and design, Component-level design, Design for reuse

3. Using APIs 5 Hours
API Programming, Class browsers and related tools, Programming by example, Debugging in the
API environment, Introduction to component-based computing

4. Software tools and environments 3 Hours
Programming environments, Requirements analysis and design modeling tools, Testing tools,
Configuration management tools, Tools integration mechanisms

5. Software Processes 2 Hours
Software life-cycle and process models, Process assessment models, Software process metrics

6. Software requirements and specifications 4 Hours
Requirements elicitation, Requirements analysis modeling techniques, Functional and
nonfunctional requirements, Prototyping, Basic concepts of formal specification techniques

7. Software validation 3 Hours
Validation planning, Testing fundamentals, including test plan creation and test case generation,
Black-box and white-box testing techniques, Unit integration, validation, and system testing,
Object-oriented testing, Inspections

8. Software evolution 3 Hours
Software maintenance, Characteristics of maintainable software, Reengineering, Legacy systems,
Software reuse

9. Software Project management 3 Hours
Team management (Team processes, Team organization and decision-making, Roles and
responsibilities in a software team, Role identification and assignment, Project tracking, Team
problem resolution), Project scheduling, Software measurement and estimation techniques, Risk
analysis, Software quality assurance, Software configuration management, Project management
tools

10. Formal methods 6 Hours
Formal methods concepts, Formal specification languages, Executable and non-executable
specifications, Pre and post assertions, Formal verification

11. Specialized Systems development 5 Hours
Real-time systems, Client-server systems, Distributed systems, Parallel systems, Web-based
systems, High-integrity systems

Main Texts:
1. Sommerville I, Software Engineering, 6th Edition PEA.
2. Pressman R, Software Engineering Practitioners Approach 5th Edition MC GrawHill
1. Introduction to Software Engineering
SOFTWARE ENGINEERING: A DEFINITION
The computer science discipline concerned with developing large applications. Software engineering
covers not only the technical aspects of building software systems, but also management issues, such as
directing programming teams, scheduling, and budgeting.
Software engineering is:
a modeling activity -- software engineers deal with complexity through modeling, by focusing at
any one time on only the relevant details and ignoring everything else.
o model -- an abstraction of reality
o analysis -- constructing a model of the problem domain
o design -- constructing a model of the solution domain
o In OO methods, the solution domain model is an extension of the problem domain model,
so that the structure of the software reflects that of the problem.
a problem-solving activity -- models are used to search for an acceptable solution
o driven by experimentation
o reuses pattern solutions
o incremental evolution of the system toward one acceptable to the client
o revised in response to change
a knowledge acquisition activity -- in modeling the application and solution domain, software
engineers collect data, organize it into information, and formalize it into knowledge.
o nonlinear -- new information may invalidate previous knowledge
risk-based development -- identify high-risk components to avoid late surprises
issue-based development -- execute development activities in parallel, organizing
according to issues which still need resolution
iterative development -- design and implement the high-risk (difficult) parts first
a rationale-driven activity -- software engineers need to capture the context in which decisions
were made and the rationale behind these decisions in order to understand the implications of a
proposed change when revisiting a decision.
o assists in dealing with changing systems
o useful in the maintenance phase
Wasserman identifies eight fundamental notions that form the basis for an effective discipline of
software engineering:
Abstraction -- a description of the problem at some level of generalization that allows us to
concentrate on the key aspects of the problem without getting mired in the details
Analysis and Design Methods and Notations -- when you work as a team, you must
communicate with many other participants in the development process, and therefore need a
common notation for communication and documentation
Prototyping -- building a small version of a system, usually with limited functionality, helps the
user to identify the key requirements of a system and demonstrates the feasibility of a design or
approach; commonly used to design a good user interface
Software Architecture -- the description of a system in terms of a set of architectural units, and
a map of how the units relate to one another
Software Process -- the organization and discipline in the activities of the process of developing
software (as well as to the products that result) contribute to the quality of the software and the
speed with which it is developed
Reuse -- taking advantage of the commonalities across applications by reusing items from
previous development
Measurement -- quantitative descriptions of improvements to processes, resources, and
methods permit us to compare progress across disparate projects and support analysis and
decision-making
Tools and Integrated Environment -- computer-aided software engineering (CASE) tools are
designed to enhance software development, but rarely address the entire software development
life cycle.
The scope of software engineering is extremely broad. In general, five aspects are involved:
o Historical Aspects
o Economic Aspects
o Maintenance Aspects
o Requirements, Analysis, and Design Aspects
o Team Development Aspects
What is the difference between building bridges and building operating systems?
Answer: Bridges are engineered to withstand every reasonably anticipated condition; while operating
systems are often built so that damages caused by unanticipated conditions are minimized.
Corollary: Bridges are assumed to be perfectly engineered; while operating systems are assumed to be
imperfectly engineered.
Another major difference: Bridges are not drastically modified during its useful life; while operating
systems are often drastically modified. (People don't rotate the bridge 90% in the maintenance phase,
but people do want to modify a batch operating system so that it supports time-sharing operation!)
Software Engineering is defined as the discipline whose aim is the production of fault-free or fault-
tolerant software that satisfies the user's needs and that is delivered on time and within budget.
The software engineer job encompasses a fairly wide range of responsibilities.
Smaller applications and systems may employ just a few software engineers to manage the full lifecycle
software development process. Generally, for most large-scale applications, jobs are broken down into
groups that focus on one specific area of the software or just a specific function of the application or
technology. For example, one system may employ a Software Architect, Design Engineer, Java
Developer and Quality Assurance Engineer.
In todays market, jobs involving web services have become more common as businesses continue to
leverage capabilities of the Internet. Object-oriented analysis and design has is a common
requirements for most business application design. Many of the responsibilities listed below are vague
and general, focusing more on software engineering in a corporate setting. This does not encompass
every possible software engineering responsibility and there are other specialized software
engineering positions such as embedded software engineers.
Common alternate job titles for Software Engineer include: Senior Software Engineer, Software
Developer, Software Programmer, Software Designer, Principal Engineer, Application Developer,
Application Engineer, Embedded Software Engineer, Java Developer, Java Engineer, Web Services
Developer, C++ Developer, Quality Assurance Engineer. Consultants can focus under any category but
most technology-consulting professionals possess experience in two or more of these areas as a
specialty.
Common Job Responsibilities for Software Engineer
1. Full lifecycle application development

2. Designing, coding and debugging applications in various software languages.
3. Software analysis, code analysis, requirements analysis, software review, identification of code
metrics, system risk analysis, software reliability analysis
4. Object-oriented Design and Analysis (OOA and OOD)
5. Software modeling and simulation
6. Front end graphical user interface design
7. Software testing and quality assurance
8. Performance tuning, improvement, balancing, usability, automation.
9. Support, maintain and document software functionality
10. Integrate software with existing systems
11. Evaluate and identify new technologies for implementation
12. Project Planning and Project Management
13. Maintain standards compliance
14. Implement localization or globalization of software
Common IT Hardware, Software, Platform and Systems Knowledge
C, C++, Java, .NET, Python, BEA WebLogic, WebSphere, J2EE, JBoss, ADO, Perl, HTML, JSP, JavaScript,
Web services, SOAP, XML, ASP, JSP, PHP, MySQL, SQL Server, Oracle, UNIX, Linux, Redhat Linux, STL,
XSLT, OWL, AJAX, J2EE, J2ME, J2SE, Sun Solaris.
Software Engineer:
A software engineer is a skilled professional focused on the design and creation of software. They may or
may not actually code. Because they are interacting with both business functions and programmers,
Software Engineers should have excellent communication skills and should enjoy working as part of a
team. They will often have to explain business functions to programmers and technology restraints to
non-technical business managers.
Requirements for Software Engineers:
Skill Set:
Successful Software Engineers need to know basic business functions, have a firm understanding of
design methodology, and excellent communication skills.
Education:
Usually requires at least a BS in Computer Science. Should be very familiar with specialized languages
relevant to the technologies employed (Java, C++,C#.NET)
Code Requirements:
Software Engineers may or may not write code, although most do regularly.
Software Engineer Compensation:
Expected Salary: Compensation for Software Engineers varies according to years of experience, degree
and geography.
Additional Incentives: Often, performance bonuses are awarded in addition to base salary. Profit
sharing or stock purchase programs may provide additional compensation. Many newer start ups
offer stock in addition to or in place of some base salary compensation.

Software Engineering Code of Ethics and Professional Practice

Software engineers shall commit themselves to making the analysis, specification, design, development,
testing and maintenance of software a beneficial and respected profession. In accordance with their
commitment to the health, safety and welfare of the public, software engineers shall adhere to the
following Eight Principles:
Software Engineering Code of Ethics and Professional Practice
SHORT VERSION
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of
their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the
highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional
judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote
an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession
consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.

FULL VERSION

Computers have a central and growing role in commerce, industry, government, medicine, education,
entertainment and society at large. Software engineers are those who contribute by direct participation
or by teaching, to the analysis, specification, design, development, certification, maintenance and testing
of software systems. Because of their roles in developing software systems, software engineers have
significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to
influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used
for good, software engineers must commit themselves to making software engineering a beneficial and
respected profession. In accordance with that commitment, software engineers shall adhere to the
following Code of Ethics and Professional Practice.
The Code contains eight Principles related to the behavior of and decisions made by
professional software engineers, including practitioners, educators, managers, supervisors and policy
makers, as well as trainees and students of the profession. The Principles identify the ethically
responsible relationships in which individuals, groups, and organizations participate and the primary
obligations within these relationships. The Clauses of each Principle are illustrations of some of the
obligations included inthese relationships. These obligations are founded in the software engineers
humanity, in special care owed to people affected by the work of software engineers, and the unique
elements of the practice of software engineering. The Code prescribes these as obligations of anyone
claiming to be or aspiring to be a software engineer.
It is not intended that the individual parts of the Code be used in isolation to justify errors of omission or
commission. The list of Principles and Clauses is not exhaustive. The Clauses should not be read as
separating the acceptable from the unacceptable in professional conduct in all practical situations. The
Code is not a simple ethical algorithm that generates ethical decisions. In some situations standards may
be in tension with each other or with standards from other sources. These situations require the
software engineer to use ethical judgment to act in a manner, which is most consistent with the spirit of
the Code of Ethics and Professional Practice, given the circumstances.
Ethical tensions can best be addressed by thoughtful consideration of fundamental principles, rather
than blind reliance on detailed regulations. These Principles should influence software engineers to
consider broadly who is affected by their work; to examine if they and their colleagues are treating other
human beings with due respect; to consider how the public, if reasonably well informed, would view
their decisions; to analyze how the least empowered will be affected by their decisions; and to consider
whether their acts would be judged worthy of the ideal professional working as
a software engineer. In all these judgments concern for the health, safety and welfare of the public is
primary; that is, the "Public Interest" is central to this Code.
The dynamic and demanding context of software engineering requires a code that is adaptable and
relevant to new situations as they occur. However, even in this generality, the Code provides support
for software engineers and managers of software engineers who need to take positive action in a specific
case by documenting the ethical stance of the profession. The Code provides an ethical foundation to
which individuals within teams and the team as a whole can appeal. The Code helps to define those
actions that are ethically improper to request of a software engineer or teams of software engineers.
The Code is not simply for adjudicating the nature of questionable acts; it also has an important
educational function. As this Code expresses the consensus of the profession on ethical issues, it is a
means to educate both the public and aspiring professionals about the ethical obligations of
all software engineers.
PRINCIPLES
Principle 1: PUBLIC
Software engineers shall act consistently with the public interest. In particular, software engineers shall,
as appropriate:
1.01. Accept full responsibility for their own work.
1.02. Moderate the interests of the software engineer, the employer, the client and the users with the
public good.
1.03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes
appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. The
ultimate effect of the work should be to the public good.
1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the public,
or the environment, that they reasonably believe to be associated with software or related documents.
1.05. Cooperate in efforts to address matters of grave public concern caused by software, its installation,
maintenance, support or documentation.
1.06. Be fair and avoid deception in all statements, particularly public ones, concerning software or
related documents, methods and tools.
1.07. Consider issues of physical disabilities, allocation of resources, economic disadvantage and other
factors that can diminish access to the benefits of software.
1.08. Be encouraged to volunteer professional skills to good causes and contribute to public education
concerning the discipline.
Principle 2: CLIENT AND EMPLOYER
Software engineers shall act in a manner that is in the best interests of their client and employer,
consistent with the public interest. In particular, software engineers shall, as appropriate:
2.01. Provide service in their areas of competence, being honest and forthright about any limitations of
their experience and education.
2.02. Not knowingly use software that is obtained or retained either illegally or unethically.
2.03. Use the property of a client or employer only in ways properly authorized, and with the client's or
employer's knowledge and consent.
2.04. Ensure that any document upon which they rely has been approved, when required, by someone
authorized to approve it.
2.05. Keep private any confidential information gained in their professional work, where such
confidentiality is consistent with the public interest and consistent with the law.
2.06. Identify, document, collect evidence and report to the client or the employer promptly if, in their
opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or
otherwise to be problematic.
2.07. Identify, document, and report significant issues of social concern, of which they are
aware, in software or related documents, to the employer or the client.
2.08. Accept no outside work detrimental to the work they perform for their primary employer.
2.09. Promote no interest adverse to their employer or client, unless a higher ethical concern is being
compromised; in that case, inform the employer or another appropriate authority of the ethical concern.
Principle 3: PRODUCT
Software engineers shall ensure that their products and related modifications meet the highest
professional standards possible. In particular, software engineers shall, as appropriate:
3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are
clear to and accepted by the employer and the client, and are available for consideration by the user and
the public.
3.02. Ensure proper and achievable goals and objectives for any project on which they work or propose.
3.03. Identify, define and address ethical, economic, cultural, legal and environmental issues related to
work projects.
3.04. Ensure that they are qualified for any project on which they work or propose to work by an
appropriate combination of education and training, and experience.
3.05. Ensure an appropriate method is used for any project on which they work or propose to work.
3.06. Work to follow professional standards, when available, that are most appropriate for the task at
hand, departing from these only when ethically or technically justified.
3.07. Strive to fully understand the specifications for software on which they work.
3.08. Ensure that specifications for software on which they work have been well documented, satisfy the
users requirements and have the appropriate approvals.
3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any
project on which they work or propose to work and provide an uncertainty assessment of these
estimates.
3.10. Ensure adequate testing, debugging, and review of software and related documents on which they
work.
3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted,
for any project on which they work.
3.12. Work to develop software and related documents that respect the privacy of those who will be
affected by that software.
3.13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways
properly authorized.
3.14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences.
3.15 Treat all forms of software maintenance with the same professionalism as new development.
Principle 4: JUDGMENT
Software engineers shall maintain integrity and independence in their professional

judgment. In particular, software engineers shall, as appropriate:
4.01. Temper all technical judgments by the need to support and maintain human values.
4.02 Only endorse documents either prepared under their supervision or within their areas of
competence and with which they are in agreement.
4.03. Maintain professional objectivity with respect to any software or related documents they are asked
to evaluate.
4.04. Not engage in deceptive financial practices such as bribery, double billing, or other improper
financial practices.
4.05. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or
escaped.
4.06. Refuse to participate, as members or advisors, in a private, governmental or professional body

concerned with software related issues, in which they, their employers or their clients have undisclosed
potential conflicts of interest.
Principle 5: MANAGEMENT
Software engineering managers and leaders shall subscribe to and promote an ethical approach to the
management of software development and maintenance . Inparticular, those managing or
leading software engineers shall, as appropriate:
5.01 Ensure good management for any project on which they work, including effective procedures for
promotion of quality and reduction of risk.
5.02. Ensure that software engineers are informed of standards before being held to them.
5.03. Ensure that software engineers know the employer's policies and procedures for protecting
passwords, files and information that is confidential to the employer or confidential to others.
5.04. Assign work only after taking into account appropriate contributions of education and experience
tempered with a desire to further that education and experience.
5.05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any
project on which they work or propose to work, and provide an uncertainty assessment of these
estimates.
5.06. Attract potential software engineers only by full and accurate description of the conditions of
employment.
5.07. Offer fair and just remuneration.
5.08. Not unjustly prevent someone from taking a position for which that person is suitably qualified.
5.09. Ensure that there is a fair agreement concerning ownership of any software, processes, research,
writing, or other intellectual property to which a software engineer has contributed.
5.10. Provide for due process in hearing charges of violation of an employer's policy or of this Code.
5.11. Not ask a software engineer to do anything inconsistent with this Code.
5.12. Not punish anyone for expressing ethical concerns about a project.
Principle 6: PROFESSION
Software engineers shall advance the integrity and reputation of the profession consistent with the
public interest. In particular, software engineers shall, as appropriate:
6.01. Help develop an organizational environment favorable to acting ethically.
6.02. Promote public knowledge of software engineering.
6.03. Extend software engineering knowledge by appropriate participation in professional organizations,

meetings and publications.
6.04. Support, as members of a profession, other software engineers striving to follow this Code.
6.05. Not promote their own interest at the expense of the profession, client or employer.
6.06. Obey all laws governing their work, unless, in exceptional circumstances, such compliance
is inconsistent with the public interest.
6.07. Be accurate in stating the characteristics of software on which they work, avoiding not only false
claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive,
misleading, or doubtful.
6.08. Take responsibility for detecting, correcting, and reporting errors in software and associated
documents on which they work.
6.09. Ensure that clients, employers, and supervisors know of the software engineer's commitment to
this Code of ethics, and the subsequent ramifications of such commitment.
6.10. Avoid associations with businesses and organizations which are in conflict with this code.
6.11. Recognize that violations of this Code are inconsistent with being a professional software engineer.
6.12. Express concerns to the people involved when significant violations of this Code are detected
unless this is impossible, counter-productive, or dangerous.
6.13. Report significant violations of this Code to appropriate authorities when it is clear that
consultation with people involved in these significant violations is impossible, counter-productive or
dangerous.
Principle 7: COLLEAGUES
Software engineers shall be fair to and supportive of their colleagues. In particular, software engineers
shall, as appropriate:
7.01. Encourage colleagues to adhere to this Code.
7.02. Assist colleagues in professional development.
7.03. Credit fully the work of others and refrain from taking undue credit.
7.04. Review the work of others in an objective, candid, and properly-documented way.
7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.
7.06. Assist colleagues in being fully aware of current standard work practices including policies and
procedures for protecting passwords, files and other confidential information, and security
measures in general.
7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client
or public interest may compel software engineers, in good faith, to question the competence of a
colleague.
7.08. In situations outside of their own areas of competence, call upon the opinions of other
professionals who have competence in that area.
Principle 8: SELF
Software engineers shall participate in lifelong learning regarding the practice of their profession and
shall promote an ethical approach to the practice of the profession. In particular, software engineers
shall continually endeavor to:
8.01. Further their knowledge of developments in the analysis, specification, design, development,
maintenance and testing of software and related documents, together with the management of the
development process.
8.02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and
within a reasonable time.
8.03. Improve their ability to produce accurate, informative, and well-written documentation.
8.04. Improve their understanding of the software and related documents on which they work and of the
environment in which they will be used.
8.05. Improve their knowledge of relevant standards and the law governing the software and related
documents on which they work.
8.06 Improve their knowledge of this Code, its interpretation, and its application to their work.
8.07 Not give unfair treatment to anyone because of any irrelevant prejudices.
8.08. Not influence others to undertake any action that involves a breach of this Code.
8.09. Recognize that personal violations of this Code are inconsistent with being a
professional software engineer.
This Code was developed by the ACM/IEEE-CS joint task force on Software Engineering Ethics and Professional Practices (SEEPP).

Software is a computer programs and its associated document and configuration data, which is needed
to make these programs operate correctly. A software system usually consists of a number of separate
programs, configuration files that are used to set up these programs, system documentation which
describes the structure of the system and user documentation which explains how to use the system, and
for software products, web sites for users to download recent information.

Software is...
Instructions ( computer programs) that when executed provide desired function and performance.
Data structures that enables the programs to adequately manipulate information, and
Documents that describe the operation and use of the programs.

Evolving role of software
Software takes on a dual role. It is a product and the vehicle for delivering a product. As a product, it
delivers the computing potential embodied by computer hardware or, a network of computers that are
accessible by local hardware. Software is an information transformer-producing, managing, acquiring,
modifying, displaying, or transmitting information. As the vehicle used to deliver the product, software
acts as the basis for the control of the computer ( operating systems), the communication of information(
networks), and the creation and control of other programs ( software tools and environments).

Software delivers the most important product of our time- information. Software transforms personal
data ( e.g., an individual's financial transactions) so that the data can be more useful in a local context; it
manages business information to enhance competitiveness; it provides a gateway to worldwide
information networks ( Internet) and provides the means for acquiring information in all of its form.

Software Characteristics
Software is a logical rather than a physical system element. Therefore, software has characteristics that
are considerably different than those of hardware. When hardware is built, the human creative process (
analysis, design, construction, testing) is ultimately translated into a physical form.

Software is developed or engineered, it is not manufactured in the classical sense.
Software does not "wear out" but it does deteriorate.
Currently, most software is still custom-built.

Attributes of a good Software
The software should deliver the required functionality and performance to the user and should be
maintainable, dependable and usable.
n Maintainability
Software must evolve to meet changing needs of the customers. This is a critical attribute
because software change is an inevitable consequence of a changing business environment.

n Dependability
Software must be trustworthy. Dependability has a range of characteristics, including
reliability, security and safety. Dependable software should not cause physical or economical
damage in the event of system failure.

n Efficiency
Software should not make wasteful use of system resources such as memory and processor
cycles. Efficiency therefore includes responsiveness, processing time, and memory
utilization, etc.

n Usability
Software must be usable by the users for which it was designed, this means it should have an
appropriate user interface and adequate documentation.

Software Applications
System software
Real-time software
Business software
Engineering and scientific software
Embedded software
Personal computer software
Web-based software
Artificial intelligence software

System software
A collection of programs written to service other programs.
Some systems software ( e.g., compilers, editor, and file management utilities) process complex,
but determinate, information structures.
Other system applications ( e.g. operating system components, drivers, telecommunications
processors) process largely indeterminate data.
It is characterized by heavy interaction with computer hardware, heavy usage by multiple users;
concurrent operation that requires scheduling, resources sharing, and sophisticated process
management, complex data structures, and multiple external interfaces.

Real time Software

It monitors/analyzes/ controls real-world events as they occur.
Elements of real time software include
o Data gathering component that collects and formats information from an external
environment,
o Analysis component that transforms information as required by the applications,
o Control/Output components that responds to the external environment,
o Monitoring component that coordinates all other components so that real time
response can be maintained.

Business Software
Business information processing is the largest single software application area.
Discrete "system" ( e.g., payroll, accounts receivable/payable, inventory) has evolved into MIS
software that access database containing business information.
Encompass interactive computing (e.g., point of sale transaction processing)

Engineering and Scientific Software
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.
Ex- CAD, System simulation and other interactive applications.

Embedded Software
Resides in ROM ( Read only memory) and is used to control products and systems for the
consumer and industrial markets.
Perform very limited and esoteric functions ( e.g., keypad control for the microwave oven)
Provide significant function and control capability ( e.g., digital functions in an automobile such
as fuel control, dashboard displays, and braking systems.)

Personal computer software
Word processing, spreadsheets, computer graphics, multimedia, entertainment, database management,
personal and business financial applications, external network, and database access.

Web-based Software
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

It makes use of non-numerical algorithms to solve complex problems that are not amenable to
computation or straightforward analysis.
Ex- Expert systems, also called knowledge based systems, pattern recognition ( image and voice),
artificial neural networks, theorem proving, and game playing.

Programs vs. Software products

Program Software Product
Programs are developed by individuals for their Software products are usually developed by a
personal use. group of software engineers and have multiple
users.
Small in size and have limited functionality Medium or large size program and have complex
functionality.
The author of a program himself uses and Software products are too large to be developed by
maintains his programs. any individual programmer. A group of software
engineers are involved in the development.
Program usually do not have good user-interface A software product not only consists of the
and lack proper documentation program code but also of all the associated
documents such as SRS document, design
document, test document and users manuals.

Software products
Software Products may be developed for a particular customer or may be developed for a general
market. There are two types of software products:

Generic products: These are stand-alone systems which are produced by a development
organization and sold on the open market to a range of different customers. Sometimes they are
referred to as shrink-wrapped software. Examples: databases, word processors, drawing packages
and project management tools.

Bespoke (or customised) products - These are systems developed for a single customer
according to their specification. Examples: control systems for electronic devices, systems written
to support a particular business process and air traffic control systems.

An important difference between these different types of software is that, in generic products, the
organization, which develops the software, controls the software specification. For custom products, the
specification is usually developed and controlled by the organization that is buying the software. The
software developers must work to that specification.

Software Myths
Software standards provide software engineers with all the guidance they need. The reality is the
standards may be outdated and rarely referred to.

People with modern computers have all the software development tools. The reality is that CASE
tools are more important than hardware to producing high quality software, yet they are rarely used
effectively.

Adding people is a good way to catch up when a project is behind schedule. The reality is that adding
people only helps the project schedule when is it done in a planned, well-coordinated manner.

Giving software projects to outside parties to develop solves software project management
problems. The reality is people who cant manage internal software development problems will
struggle to manage or control the external development of software too.

A general statement of objectives from the customer is all that is needed to begin a software project.
The reality is without constant communication between the customer and the developers it is
impossible to build a software product that meets the customer's real needs.

Project requirements change continually and change is easy to accommodate in the software design.
The reality is that every change has far-reaching and unexpected consequences. Changes to software
requirements must be managed very carefully to keep a software project on time and under budget.

Once a program is written, the software engineer's work is finished. The reality is that maintaining a
piece of software is never done, until the software product is retired from service.

There is no way to assess the quality of a piece of software until it is actually running on some
machine. The reality is that one of the most effective quality assurance practices (formal technical
reviews) can be applied to any software design product and can serve as a quality filter very early in
the product life cycle.

The only deliverable from a successful software project is the working program. The reality is the
working program is only one of several deliverables that arise from a well-managed software
project. The documentation is also important since it provides a basis for software support after
delivery.

Software engineering is all about the creation of large and unnecessary documentation. The reality is
that software engineering is concerned with creating quality. This means doing things right the first
time and not having to create deliverables needed to complete or maintain a software product. This
practice usually leads to faster delivery times and shorter development cycles.

Summary
Software has become a key element in the evolution of computer based systems and products. Over the
past 50 years, software has evolved from a specialized problem solving and information analysis tool to
an industry in itself. Since software is composed of programs, data and documents; each of these items
comprises a configuration that is created as part of the software engineering process. The intent of
software engineering is to provide a framework for building software with higher quality.
Software engineering is the systematic collection of decades of programming experience together with
the innovations made by researchers towards developing high-quality software in a cost effective maner.

Assignment Questions

Q1. Software is both a product and a vehicle for delivering a product. Explain

Q2. Software is engineered, not manufactured. Explain

Q3. Software does not wear, but it does deteriorate. Describe this statement with reference to software
characteristics.

Q4. Define Software and explain its characteristics and also mention the various types of software
product.

Q5. Explain some of the Software applications you have noticed.

Q6. Compare and contrast programs with Software products.

Q7. What are the various software myth and explain what should be the reality.

Q8. What are the key challenges facing software engineering?
2. Design Concepts and Principles
Overview
A software design is a meaningful engineering representation of some software product that is to be

built. A design can be traced to the customer's requirements and can be assessed for quality against
predefined criteria. During the design process the software requirements model is transformed into
design models that describe the details of the data structures, system architecture, interface, and
components. Each design product is reviewed for quality before moving to the next phase of software
development.

Software design sits at the technical kernel of software engineering and is applied regardless of the
software process model being used. Beginning once software requirements have been analyzed and
specified, software design is the first of three technical activities-design, code generation, and test - that
are required to build and verify the software. Each activity transforms information in a manner that
ultimately results in validated computer software.

Design Specification Models

Data design - created by transforming the analysis information model (data dictionary and ERD)
into data structures required to implement the software
Architectural design - defines the relationships among the major structural elements of the
software, it is derived from the system specification, the analysis model, and the subsystem
interactions defined in the analysis model (DFD)
Interface design - describes how the software elements communicate with each other, with other
systems, and with human users; the data flow and control flow diagrams provide much the
necessary information
Component-level design - created by transforming the structural elements defined by the
software architecture into procedural descriptions of software components using information
obtained from the PSPEC, CSPEC, and STD

Design Guidelines
A design should
exhibit good architectural structure
be modular
contain distinct representations of data, architecture, interfaces, and components (modules)
lead to data structures that are appropriate for the objects to be implemented and be drawn from
recognizable design patterns
lead to components that exhibit independent functional characteristics
lead to interfaces that reduce the complexity of connections between modules and with the
external environment
be derived using a reputable method that is driven by information obtained during software
requirements analysis

Design Principles
Software design is both a process and a model. The design process is a sequence of steps that enable the
designer to describe all aspects of the software to be built. The design model is the equivalent of an
architect's plan for a house. It begins by representing the totality of the thing to be built and slowly
refines the thing to provide guidance for constructing each detail.

Basic design principles, as suggested by Davis, enable to navigate the design process.

The design
process should not suffer from "tunnel vision"
should be traceable to the analysis model
should not reinvent the wheel
should "minimize intellectual distance" between the software and the problem as it exists in the
real world
should exhibit uniformity and integration
should be structured to accommodate change
should be structured to degrade gently, even with bad data, events, or operating conditions are
encountered
should be assessed for quality as it is being created
should be reviewed to minimize conceptual (semantic) errors

Fundamental Software Design Concepts

Abstraction - allows designers to focus on solving a problem without being concerned about
irrelevant lower level details (procedural abstraction - named sequence of events, data
abstraction - named collection of data objects)
Refinement - process of elaboration where the designer provides successively more detail for
each design component
Modularity - the degree to which software can be understood by examining its components
independently of one another
Software architecture - overall structure of the software components and the ways in which that
structure provides conceptual integrity for a system
Control hierarchy or program structure - represents the module organization and implies a
control hierarchy, but does not represent the procedural aspects of the software (e.g. event
sequences)
Structural partitioning - horizontal partitioning defines three partitions (input, data
transformations, and output); vertical partitioning (factoring) distributes control in a top-down
manner (control decisions in top level modules and processing work in the lower level modules)
Data structure - representation of the logical relationship among individual data elements
(requires at least as much attention as algorithm design)
Software procedure - precise specification of processing (event sequences, decision points,
repetitive operations, data organization/structure)
Information hiding - information (data and procedure) contained within a module is inaccessible
to modules that have no need for such information

Modular Design Method Evaluation Criteria
Modular decomposability - provides systematic means for breaking problem into sub-problems
Modular composability - supports reuse of existing modules in new systems
Modular understandability - module can be understood as a stand-alone unit
Modular continuity - side-effects due to module changes minimized
Modular protection - side-effects due to processing errors minimized

Control Terminology
Span of control (number of levels of control within a software product)
Depth (distance between the top and bottom modules in program control structure)
Fan-out or width (number of modules directly controlled by a particular module)
Fan-in (number of modules that control a particular module)
Visibility (set of program components that may be called or used as data by a given component)
Connectivity (set of components that are called directly or are used as data by a given
component)

Effective Modular Design
Functional independence - modules have high cohesion and low coupling
Cohesion - qualitative indication of the degree to which a module focuses on just one thing
Coupling - qualitative indication of the degree to which a module is connected to other modules
and to the outside world

Design Heuristics for Effective Modularity
Evaluate the first iteration of the program structure to reduce coupling and improve cohesion.
Attempt to minimize structures with high fan-out; strive for fan-in as structure depth increases.
Keep the scope of effect of a module within the scope of control for that module.
Evaluate module interfaces to reduce complexity, reduce redundancy, and improve consistency.
Define modules whose function is predictable and not overly restrictive (e.g. a module that only
implements a single sub-function).
Strive for controlled entry modules, avoid pathological connection (e.g. branches into the middle
of another module)

Assignments

1) Do you design software when you "write" a program? What makes software design different from
coding?

2) Discuss the relationship between the concept of information hiding as an attribute of effective
modularity and the concept of module independence.

3) Discuss how structural partitioning can help to make software more maintainable.

4) What is the purpose of developing a program structure that is factored?

5) Explain the different design principles.

6) Explain Top-down Vs. Bottom-up design technique

7) Write short notes on Fan-in and Fan-out
3. Using APIs
Application programming interface (API)
An application-programming interface (API) is a particular set of rules and specifications that software
programs can follow to communicate with each other. It serves as an interface between different software
programs and facilitates their interaction; similar to the way the user interface facilitates interaction between
humans and computers.
An API can be created for applications, libraries, operating systems, etc., as a way of defining their
"vocabularies" and resources request conventions (e.g. function-calling conventions). It may include
specifications for routines, data structures, object classes, and protocols used to communicate between the
consumer program and the implementer program of the API.
An API is an abstraction that describes an interface for the interaction with a set of functions used by
components of a software system. The software providing the functions described by an API is said to be
an implementation of the API.
An API can be:
General, the full set of an API that is bundled in the libraries of a programming language, e.g. Standard
Template Library in C++ or Java API.
Specific, meant to address a specific problem, e.g. Google Maps API or Java API for XML Web Services.
Language-dependent, meaning it is only available by using the syntax and elements of a particular
language, which makes the API more convenient to use.
Language-independent, written so that it can be called from several programming languages. This is a
desirable feature for a service-oriented API that is not bound to a specific process or system and may be
provided as remote procedure calls or web services. For example, a website that allows users to review
local restaurants is able to layer their reviews over maps taken from Google Maps, because Google Maps
has an API that facilitates this functionality. Google Maps' API controls what information a third-party site
can use and how they can use it.
API may be used to refer to a complete interface, a single function, or even a set of APIs provided by an
organization. Thus, the scope of meaning is usually determined by the context of usage.
You often have to rely on others to perform functions that you may not be able or permitted to do by
yourself, such as opening a bank safety deposit box. Similarly, virtually all software has to request other
software to do some things for it.
To accomplish this, the asking program uses a set of standardized requests, called application programming
interfaces (API), that have been defined for the program being called upon. Almost every application depends
on the APIs of the underlying operating system to perform such basic functions as accessing the file system. In
essence, a program's API defines the proper way for a developer to request services from that program.
Developers can make requests by including calls in the code of their applications. The syntax is described in
the documentation of the application being called. By providing a means for requesting program services, an
API is said to grant access to or open an application.
Building an application with no APIs, is basically like building a house with no doors. The API for all computing
purposes is how you open the blinds and the doors and exchange information. APIs also exist between
applications.
Open source code exposes every instruction and operation in an application and therefore offers the most
flexibility. But understanding source code can be time-consuming, and it also exposes the author's intellectual
property.
Class browser
A class browser is a feature of an integrated development environment (IDE) that allows the programmer to
browse, navigate, or visualize the structure of object-oriented programming code.
All major development environments supply some manner of class browser, including
CodeWarrior for Microsoft Windows, Mac OS, and embedded systems
Microsoft Visual Studio
Eclipse
Embarcadero JBuilder
Embarcadero Delphi
Apple Xcode for Mac OS X
NetBeans
KDevelop
Cincom Smalltalk
.NET Reflector
Visual Prolog
Programming by example (PbE),
Programming by example (PbE), also known as programming by demonstration or more generally

as demonstrational programming, is an End-user development technique for teaching
a computer new behavior by demonstrating actions on concrete examples. The system records user actions
and infers a generalized program that can be used upon new examples.
PbE is intended to be easier than traditional programming, which generally requires learning and using
a programming language. Many PbE systems have been developed as research prototypes, but few have
found widespread real-world application. More recently, PbE has proved to be a useful paradigm for creating
scientific work-flows.
Programming by example is a way of programming a software system in its own user interface. The user of
the system writes a program by giving an example of what the program should do. The system records the
sequence of actions, and can perform it again. Programming by example allows a user to create programs
without doing conventional programming. Programming by example was incorporated into a simulation of an
office information system. As the system evolved, it became clear that the basic concept of programming by
example needed to be extended: certain aspects of program creation are better done by program
modification than by using the programming-by-example mechanism. The final system includes a static
program representation that is easy to understand, a mechanism for describing data, and a method of adding
control structure. A user operates on certain data while creating a program by example, but does not
necessarily tell the system why that data was selected. The user can supply this missing information by using
data descriptions, which are program operands that specify how to choose the data to be used when the
program is run. The system automatically supplies reasonable default data descriptions while recording a
program; if necessary the user can modify the descriptions later to reflect his or her true intentions.
Since programming by example is best at recording sequential user actions, rather than branching or
iteration, control structure that alters program flow is specified by program editing. The operands in
iterations and the predicates in conditional control structures are built from data descriptions. Real users
have learned to use the system quickly and with little difficulty. The techniques used in this system can be
applied to other systems as well. This research has demonstrated that programming by example is a practical
method for creating programs.
Component-based software engineering (CBSE)
Component-based software engineering (CBSE) (also known as component-based development (CBD)) is a

branch of software engineering which emphasizes the separation of concerns in respect of the wide-ranging
functionality available throughout a given software system. This practice aims to bring about an equally wide-
ranging degree of benefits in both the short-term and the long-term for the software itself and for
organizations that sponsor such software.
4. Software tools and Environments
Topics to be covered:
Programming Environment
Requirement analysis and design modeling tools
Testing tools
Configuration Management Tools
Tools Integration Mechanism
SELF STUDY
5. Software Process

An Introduction - Software Engineering

Software engineering is an engineering discipline, which is concerned with all aspects of software
production from the early stages of system specification through to maintaining the software.

Software engineers should adopt a systematic and organised approach to their work and use
appropriate tools and techniques depending on the problem to be solved, the development constraints
and the resources available

Software engineering encompasses a process, management techniques, technical methods, and the use
of tools to develop software. It provides the specification, development, management, and evolution of
software systems, not constrained by materials governed by physical laws or manufacturing processes.

According to Stephen R. Schach, Richard D.Irwin, Inc. and Aksen Associates, Software engineering is a
discipline whose aim is the production of quality software, delivered on time, within budget, and
satisfying users' needs.

According to Shari Lawrence Pfleeger,
Software Engineering is the designing and developing high-quality software. Application of computer
science techniques to a variety of problems.

According to Fritz Bauer [ NAU69],
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 [IEE93] defines Software engineering as..
(1) The application of a systematic, disciplined, quantifiable approach to development, operation,
and maintenance of software; that is, the application of engineering to software.
(2) The study of approach as in (1).
Difference between software engineering and computer science
Computer science is concerned with theory and fundamentals; software engineering is concerned with
the practicalities of developing and delivering useful software. Computer science theories are currently
insufficient to act as a complete underpinning for software engineering

Difference between software engineering and system engineering
System engineering is concerned with all aspects of computer-based systems development including
hardware, software and process engineering. Software engineering is part of this process

System engineers are involved in system specification, architectural design, integration and deployment.

Generic view of Software Engineering
Engineering is the analysis, design, construction, verification and management of technical (or social)
entities. The questions being asked are:
What is the problem to be solved?
What characteristics of the entity are used to solve the problem?
How will the entity (and the solution) be realized?
How will the entity be constructed?
What approach will be used to uncover errors that were made in the design and construction of
the entity?
How will the entity be supported over the long term, when corrections, adaptations and
enhancement are requested by users of the entity?

Generic phases of Software Engineering
1. Definition phase
2. Development Phase
3. Support Phase

1. Definition phase
It focuses on WHAT i.e. to identify what is to be processed.
What functions and performance are desired?
What design constraints exist?
What validation criteria are required to define a successful system?
Identify the key requirements of the systems and the software?
It perform three major tasks as
System or Information engineering
Software project planning
Requirement analysis

2. Development phase
It focuses on HOW i.e. to define how data are to be structured.
How function is to be implemented within a software architecture?
How procedural details are to be implemented?
How interface are to be characterized?
How the design will be translated into a programming language ( or nonprocedural language)
How testing will be performed?
It perform three specific technical tasks as
Software design
Code generation
Software testing

3. Support
It focuses on change associated with error correction, adaptations required as the software environment
evolves, and changes due to enhancements brought by the changing customer requirements.

Four types of changes are encountered during the support phases:
Correction
o Use of corrective maintenance for any error encountered during support.
Adaptation
o Use of adaptive maintenance to accommodate changes in the external environment.
o Example: Change in the CPU, OS, Business rules, external product characteristics)
Enhancement
o Use of perfective maintenance that extends the software beyond its original functional
requirements.
Prevention
o Use of preventive maintenance by conducting software re-engineering to avoid software
deterioration and to correct, adopt or enhance its features.

Software Engineering Umbrella activities

Software project tracking & control
Formal technical reviews
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management

Note: These umbrella activities overlay the process model, and are independent of any one framework
activity (Software engineering work tasks, Project milestones, Work products, Quality assurance points)
and occur throughout the process.

Software Engineering: A layered technology
Software engineering is a layered technology as referred in fig shown below. It consists of four layers as

A quality focus
Process
Methods
Tools

A quality Focus
The bedrock that supports software engineering is a quality focus. Software engineering approach must
rest on the organizational commitment to quality. Total Quality Management (TQM) philosophies that
support continuous improvement culture leads to the development of increasingly more approaches to
software engineering.

Process Layer
It is the foundation of software engineering that defines a framework for a set of KPA ( key process areas)
that must be established for effective delivery of software engineering technology. The KPA 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) are produced, milestones are
established, quality is ensured, and change is properly managed.

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

Tools
It provide automated or semi-automated support for the process and methods. Integrated tools establish
computer-aided software engineering (CASE). CASE combines software, hardware and software
engineering database to create a software engineering environment analogous to CAD/CAE ( computer
aided design/engineering) for hardware.

Tools

Methods

Process

A Quality Focus

Fig: Software Engineering Layer

Software Process
The roadmap to building high quality software products is software process.
Software processes are adapted to meet the needs of software engineers and managers as they
undertake the development of a software product.
A software process provides a framework for managing activities that can very easily get out of
control.
Different projects require different software processes.
The software engineer's work products (programs, documentation, data) are produced as
consequences of the activities defined by the software process.
The best indicators of how well a software process has worked are the quality, timeliness, and
long-term viability of the resulting software product.
A structured set of activities whose goal is the development or evolution of software
Generic activities in all software processes are:
Specification - what the system should do and its development constraints
Design/Development - production of the software system
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands

Common Process Framework
Common process framework
Framework activities
Task Sets
Tasks
Milestones, deliverables
SQA Points
Umbrella activities

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 number of task sets includes:
Software engineering work tasks
Project milestones
Work products
Quality assurance points

These task sets enable the framework activities to be adopted to the characteristics of the software
project and the requirements of the project team.

SEI-CMM ( Capability Maturity Model)
To determine an organization's current state of process maturity, the SEI uses an assessment that re-
suits in a five point grading scheme to determines compliance with a CMM (Capability Maturity Model)

SEI approach provides a measures of the global effectiveness of a company's software engineering
practices and establishes five process maturity levels. CMM defines key activities required at different
levels of process maturity.

Level 1 : Initial - ad hoc and occasionally even chaotic software processes
- few processes are defined, and success depends on individual effort.

Level 2 : Repeatable - able to repeat earlier successes
- establish basic project management to track cost, schedule &
functionality

Level 3 : Defined - management and engineering processes documented, standardized, and
integrated into organization-wide software process

Level 4 : Managed - software process and products are quantitatively understood and
controlled using detailed measures

Level 5 : Optimizing - continuous process improvement is enabled by quantitative feedback
from the process and testing innovative ideas & technologies.

Key Process Areas (KPA)

Each maturity level is associated with KPA. KPA describe those software Engineering functions ( e.g.
software project planning, requirement management) that must be present to satisfy good practice at a
particular level.
Characteristics of KPA includes:
Goals : the overall objectives that the KPA must achieve.
Commitments : requirements that must be met to achieve goals
Abilities : those things( organizationally & technically) to meet the
commitments
Activities : specific tasks required to achieve KPA function.
Monitoring : manner in which the activities are monitored.
Verification : manner in which proper practice for the KPA can be verified.

18 KPAs are defined across the maturity model & mapped into different levels of process maturity:

Process maturity level 2
Software configuration management
Software quality assurance
Software subcontract management
Software project planning
Requirements management

Peer review
Intergroup co-ordination
Software product engineering
Integrated software management
Training program
Organization process definition
Organization process focus

Software quality management
Quantitative process management

Process change management
Technology change management
Defect prevention

Software Process Models
A software process model or software engineering paradigm is a development strategy that encompasses
the process, methods and tools layers.

A software process model is an abstract representation of a process. It presents a description of a
process from some particular perspective. All software development process can be characterized as a
problem solving loop as shown in figure that consists of four distinct stages such as:
Status Quo : represents the current state of affairs.
Problem definition : identifies the specific problem to be solved.
Technical development : Solve the problem through the application of
some technology
Solution Integration : delivers the results (e.g., document, programs,
data, new business functions, new products)

Problem

Definition

Technical
Status
development
Quo

Solution
Integration

Fig : Problem solving loop

Types of Process Models
A process model is chosen based on the nature of the project and application, the methods and tools
being used, and the controls and deliverables that are required.

The following types of process models are being used in the software development:

Linear Sequential Model
o old fashioned but reasonable approach when requirements are well understood
o Separate and distinct phases of specification and development

Prototyping Model
o Good first step when customer has a legitimate need, but is clueless about the details,
developer needs to resist pressure to extend a rough prototype into a production
product.

Rapid Application and Development (RAD) Model
o makes heavy use of reusable software components with an extremely short development
cycle

Evolutionary Software process Model
Incremental Model
o delivers software in small but usable pieces, each piece builds on pieces
already delivered
Spiral Model
o couples iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model
Component-Based Development
o spiral model variation in which applications are built from prepackaged software
components called classes

1. Linear Sequential Model
This model is also known as the Waterfall model or software life cycle.
The principal stages of the model map onto fundamental development activities:
Requirements analysis and definition
v system's services, constraints and goals are established.
v details are served as system specifications.
System and software design
v partitions the requirements to either hardware or software systems.
v establishes an overall system architecture.
v identifies and describes the fundamental software system abstractions and their
relationships
Implementation and unit testing
v software design is realized as a set of programs or programs units.
v Unit test is performed to verify each unit meet its specification.
Integration and system testing
v Individual program units or programs are integrated.
v Perform test to ensure that the requirements are met.
Operation and maintenance
v It is the longest life cycle phase.
v The system is installed and put into practical use.
v Maintenance involve error correction and improving the implementation of
system units
v Enhance the system service to meet new requirements.
The drawback of the waterfall model is the difficulty of accommodating change after the process
is underway

Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

Fig: Waterfall Model
In principle, the result of each phase is one or more approved ("signed off") documents. The following
phase should not start until the previous phase has finished. In practice, these stages overlap and feed
information to each other. During design, problems with requirements are identified, during coding
design problems are found and so on. The software process is not a simple linear model but involves a
sequence of iterations of the development activities.

Because of the costs of producing and approved documents, iterations are costly and involve significant
rework. Therefore, after a small number of iterations, it is normal to freeze parts of the development,
such as the specification, and to continue with the later development stages. Problems are left for later
resolution, ignored or are programmed around. This premature freezing of requirements may means
that the system won't do what the user wants. It may also lead to badly structured systems.

Waterfall Model problems

Inflexible partitioning of the project into distinct stages
This makes it difficult to respond to changing customer requirements
Therefore, this model is only appropriate when the requirements are well-understood

2. Prototyping Model
A prototyping paradigm offers the best approach when.....

a customer defines a set of general activities for software but does not identify detailed
input, processing, or output requirements.
the developer may be unsure of the efficiency of an algorithm, the adaptability of an
operating system

It begins with requirement gathering where developer and customer, together, define the overall
objectives for the software, identify whatever requirements are known, and outline areas where
further definition is mandatory.

Develop a " quick Design " that focus on input approaches and output formats that is visible to
the customer/user. It leads to the construction of a prototype, that serves as a mechanism for
identifying software requirements

Prototype is evaluated by the customer/user and refine the requirements for the software to be
developed.

The prototype serves as " the first system" where users get a feel for the actual system and
developers get to build something immediately.


Fig: The prototyping paradigm

In this model, the key is to define the rules of the game at the beginning, that is, the customer and
developer must agree that the prototype is built to serve as a mechanism for defining requirements. It is
then discarded and the actual software is engineered considering quality and maintainability.

The prototype Model problem

Prototype appears to be the working version of the software, but all software quality and long-
term maintainability has not been considered. The final must be rebuilt.
Implementation comprises for quick working of prototype.
Use of inappropriate Operating system or programming language
Implementation of inefficient algorithm to demonstrate capability

3. The RAD Model
RAD ( Rapid application development) is an incremental software development process model with
extremely short development cycle.

It is a "high-speed" adaptation of the linear sequential model in which rapid development by using
component-based construction. RAD process enable to create a "fully functional system" within very
short time periods (e.g. 60-90 days) if requirements are well understood and project scope is
constrained.

Used primarily for information systems applications, the RAD approach encompasses the following
phases:

Business modeling
o The information flow among the business functions is modeled to answer the following
questions:
What information drives the business process?
What information is generated?
Who generates it?
Where does the information go?
Who process it?
Data modeling
o The information defined in the business-modeling phase is refined into a set of data
objects that are needed to support the business.
o The characteristics (attributes) of each objects are identified and the relationship
between these objects is defined.

Process modeling
o The data objects defined in the data modeling phase are transformed to achieve the
information flow necessary to implement a business function.
o Processing descriptions are created for adding, modifying, deleting, or retrieving a data
object.
Application generation
o Use of forth generation techniques
o Reuse existing program components or create reusable components.
o Automated tools are used to facilitate construction of the software.
Testing and turnover
o Since RAD process emphasizes reuse, many of the program components have already
been tested, that reduces overall testing time.
o Testing of new components and interfaces are done.


Team #3

Business
modelin
g
Data
Team #2
modeling
Business
Process
Team #1 modeling
modeling
Data Application
Business modelin generation
modeling g
Process Testing
modeling &
Data turnover
modeling Application
generation
Process
Testing &
modeling turnover

Application
generation

Testing &

turnover

60-90 days

Fig: The RAD Model

Drawback of RAD Model

For large and scalable projects, RAD requires sufficient human resources to create the right
number of RAD teams.
RAD requires developers and customers who are committed to the rapid-fire activities necessary
to get a system complete in a much abbreviated time frame. In the lack of commitment from
either side, RAD project fails.
If a system cannot be properly modularized, building the components necessary for RAD will be
problematic.
RAD approach cannot be used for high performance.
RAD is not appropriate when technical risks are high.


4. Evolutionary Software Process Models

The software system ALWAYS evolves over a period of time in the course of a project (due to
change in the business and products requirements) so process iteration where earlier stages are
reworked is always part of the process for large systems.

The linear sequential model is designed for straight for straight line requirement. In essence, this
waterfall approach assumes that a complete system will be delivered after the linear sequence is
completed. The prototyping model is designed to assist the customer ( or developer) in understanding
requirements. In general, it is not designed to deliver a production system. The evolutionary nature of
software is not considered in either case of these classic software engineering paradigms.

Iteration can be applied to any of the generic process models
Two (related) approaches
Incremental development model
Spiral model

4.1 Incremental Model
It combines the elements of the linear sequential model with the iterative philosophy of
prototyping.
It applies the linear sequences in the staggered fashion as calendar time progresses.
Rather than deliver the system as a single delivery, the development and delivery is broken down
into increments with each increment delivering part of the required functionality
User requirements are prioritised and the highest priority requirements are included in early
increments
Each linear sequence produces a deliverable "increment" of the software, where the process flow
for any increment can incorporate the prototyping paradigm.
The first increment results in a core product where the basic requirements are addressed, but
many supplementary features remains undelivered.
After the deployment of the core product and its evaluation, a plan is developed for the next
increment, which addresses the modification of the core product to better meet the needs of the
customer and delivery of additional features and functionality. This process is repeated following
the delivery of each increment, unit the complete product is produced.

Define outline Assign requirements Design system

requirements to increments architecture
Develop system Validate Integrate Validate

increment increment increment system
Final
system
System incomplete
Fig: Incremental development

System/information Increment 1
engineering
Delivery of 1st
Analysis Design Code Test Increment
Delivery of 2nd
Increment 2 Analysis Design Code Test Increment
Delivery of 3rd
Increment 3 Analysis Design Code Test Increment
Increment 4 Analysis Design Code Test

Delivery of 4th
Increment
Calendar Time

Fig: Incremental Model

Incremental development advantages
Customer value can be delivered with each increment so system functionality is available earlier
Early increments act as a prototype to help elicit requirements for later increments
Lower risk of overall project failure
The highest priority system services tend to receive the most testing


4.2 Spiral Model

As proposed by Boehm, it couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model.
Software is developed in a series of incremental releases.
Process is represented as a spiral rather than as a sequence of activities with backtracking
Each loop in the spiral represents a phase in the process.
No fixed phases such as specification or design - loops in the spiral are chosen depending on
what is required
Risks are explicitly assessed and resolved throughout the process.

Model is divided into a number of framework activities, called task regions that contains:
o Customer communication: task required to establish effective communication between
developer and customer.

o Planning: task required to define resources, timeliness, and other project related
information.

o Risk analysis: task required to assess both technical and management risk.

o Engineering: task required to build one or more representations of the application.

o Construction and release: tasks required to construct, test, install
and provide user support. (E.g. documentation and training)

Spiral model of the software process

Determine objectives
Evaluate alternatives
alternatives and
identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
analysis Proto-
REVIEW type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation
S/W
requirements Product
design Detailed
Development Requirement design
plan validation Code
Design Unit test
Integration
and test plan V&V Integration
Plan next phase test
Acceptance
test Develop, verify
Service
next-level product

Spiral model sectors

Objective setting
o Specific objectives for the phase are identified
Risk assessment and reduction
o Risks are assessed and activities put in place to reduce the key risks
Development and validation
o A development model for the system is chosen which can be any of the generic models
Planning
o The project is reviewed and the next phase of the spiral is planned

5. Component-based development (CBD) model
Object-oriented technologies provide the technical framework for a component-based process model
It emphasizes the creation of classes that encapsulate both data and the algorithms used to manipulate
the data.
Properly designed and implemented object-oriented classes are reusable across different applications
and computer-based system architectures.

It incorporates the characteristics of the spiral model and evolutionary in nature, demanding an iterative
approach to the creation of software. It composes applications from prepackaged software components
(called classes)

It performs the following activities:

Identification of candidate classes which is accomplished by examining the data to be manipulated by the
applications and the algorithms that will be applied to accomplish the manipulation.

Search for the class library from its library or repository of classes created earlier.

If available, extract class components for reuse, otherwise, develop using object-oriented methods.
Compose the first iteration of the application to be build, using the extracted classes from the library and
any new classes built to meet the unique needs of the application.
Process flow returns to the spiral and re-enter the component assembly iteration during subsequent
passes.

Advantages of the CBD Model
Reusability of the software.
Reduction in the development cycle time
Reduction in the project costs.
Increase in the productivity

Summary
Software engineering is a discipline that integrates process, methods, and tools for the development
of computer software.
Software processes are the activities involved in producing and evolving a software system. They are
represented in a software process model
General activities are specification, design and implementation, validation and evolution
Generic process models describe the organisation of software processes
Iterative process models describe the software process as a cycle of activities
Requirements engineering is the process of developing a software specification
Design and implementation processes transform the specification to an executable program
Validation involves checking that the system meets to its specification and user needs
Evolution is concerned with modifying the system after it is in use
CASE technology supports software process activities

Assessment Questions

1. Giving reasons for your answer based on the type of system being developed, suggest the most
appropriate generic software process model which might be used as a basis for managing the
development of the following systems:

a system to control anti-lock braking in a car.
a virtual reality system to support software engineering maintenance.
a university accounting system that replace an existing system
an interactive system for railway passengers that might finds train times from terminals installed in
stations.

2. Explain why programs which are developed using evolutionary development are likely to be difficult
to maintain.

3. Explain how both the waterfall model of the software process and the prototyping model can be
accommodated in the spiral process model.

4. Explain why a software system that is used in a real-world environment must change or become
progressively less useful.

5. IS there ever a case when the generic phases of the software engineering process don't apply? If so,
describe.

6. The SEI's capability maturity model (CMM) is an evolving document. Explain the various KPAs mapped
into each level.

7. Which of the software engineering paradigms do you think would be most effective? Why?

8. As you moved outward along the process flow path of the spiral model, what can you say about the
software that is being developed or maintained?

9. Which is more important- the product or the process?

10. "Software Engineering is a layered technology". Justify your answer.

11. Explain the term Software and Software Engineering in your own words.

12.It is true to say that information is going to be seized during waterfall model?
Explain
13. What do you mean by the term life cycle model of software development?

14. What is prototype model? Under what circumstances it beneficial to construct a prototype model?
Does the construction of a prototype model always increase the overall cost of software development?
6. Software requirements and Specifications
Analysis Concepts and Principles - Overview
After system engineering is completed, software developers need to look at the role of software in the
proposed system. Software requirements analysis is necessary to avoid creating a software product that
fails to meet the customer's needs. Data, functional, and behavioral requirements are elicited from the
customer and refined to create a specification that can be used to design the system. Software
requirements work products must be reviewed for clarity, completeness, and consistency.

Definition of requirement
Requirements set out what the system should do and define constraints on its operation and
implementation
It may range from a high-level abstract statement of a service or of a system constraint to a
detailed mathematical functional specification
This is inevitable as requirements may serve a dual function
o May be the basis for a bid for a contract - therefore must be open to interpretation
o May be the basis for the contract itself - therefore must be defined in detail
o Both these statements may be called requirements

"Software requirement is the descriptions and specifications of a system"

Types of requirements
User requirements
o Statements in natural language plus diagrams of the services the system provides and its
operational constraints. Written for customers.
System requirements
o A structured document setting out detailed descriptions of the system services. Written
as a contract between client and contractor.
Software specification
o A detailed software description which can serve as a basis for a design or
implementation. Written for developers.

Client Managers
System end-users
User requirements Client Engineers
Contractor managers
System architects
System end-users
Software requirements Client Engineers
System architects
Software developers
Client Engineers
Software design System architects
specification Software developers

Functional and Non-functional requirements
Functional requirements
Statements of services the system should provide, how the system should react to particular
inputs and how the system should behave in particular situations.
Describe functionality or system services
Depend on the type of software, expected users and the type of system where the software is
used
Functional user requirements may be high-level statements of what the system should do but
functional system requirements should describe the system services in detail

Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints,
constraints on the development process, standards, etc.
Define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.
Process requirements may also be specified mandating a particular CASE system, programming
language or development method
Non-functional requirements may be more critical than functional requirements. If these are not
met, the system is useless

Non-functional classifications
Product requirements
o Requirements which specify that the delivered product must behave in a particular way
e.g. execution speed, reliability, etc.
Organisational requirements
o Requirements which are a consequence of organisational policies and procedures e.g.
process standards used, implementation requirements, etc.
External requirements
o Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements, etc.

Domain requirements
Requirements that come from the application domain of the system and that reflect characteristics of that
domain
Derived from the application domain and describe system characteristics and features that reflect the
domain
May be new functional requirements, constraints on existing requirements or define specific computations
If domain requirements are not satisfied, the system may be unworkable

Non-functional requirement types
Non-functional
requirements
Product Organizational External

requirements requirements requirements
Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements
Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements
Performance Space Privacy Safety

requirements requirements requirements requirements
Requirements measures

Property Measure
Speed Processed transactions/second
User/Event response time
Screen refresh time
Size K bytes
Numbers of RAM chips
Ease of Use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability

Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure

Portability Percentage of target-dependent statements
Number of target systems

Requirements Engineering
Requirements Engineering provides the appropriate mechanism for understanding what the customer
wants, analyzing the need, assessing feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification, and managing the requirements as they are transformed
into a operational system.

The process of establishing the services that the customer requires from a system and the
constraints under which it operates and is developed
The requirements themselves are the descriptions of the system services and constraints that are
generated during the requirements engineering process

Requirement Engineering Process
It is the processes used to discover, analyse and validate system requirements. The processes used for
RE vary widely depending on the application domain, the people involved and the organisation
developing the requirements. However, there are a number of generic activities common to all processes
can be described in six distinct steps:
Step 1: Requirements elicitation
Step 2: Requirements analysis and negotiation
Step 3: Requirements specification
Step 4: System modeling
Step 5: Requirements validation
Step 6: Requirements management

Requirements
Feasibility
study elicitation and
analysis
Requirements
specification

Feasibility Requirements
report validation
System
models
User and system
requirements
Requirements
document

Fig: Requirement Engineering Process

Step1: Requirements elicitation (find out from customers what the product objectives are, what is to
be done, how the product fits into business needs, and how the product is used on a day to day basis)

Software Requirements Elicitation
Customer meetings are the most commonly used technique.
Use context free questions to find out customer's goals and benefits, identify stakeholders, gain
understanding of problem, determine customer reactions to proposed solutions, and assess
meeting effectiveness.
If many users are involved, be certain that a representative cross section of users is interviewed.

Facilitated Action Specification Techniques (FAST)
Meeting held at neutral site, attended by both software engineers and customers.
Rules established for preparation and participation.
Agenda suggested to cover important points and to allow for brainstorming.
Meeting controlled by facilitator (customer, developer, or outsider).
Definition mechanism (flip charts, stickers, electronic device, etc.) is used.
Goal is to identify problem, propose elements of solution, negotiate different approaches, and
specify a preliminary set of solution requirements.

Step2: Requirements analysis and negotiation (requirements are categorized and organized into
subsets, relations among requirements identified, requirements reviewed for correctness, requirements
prioritized based on customer needs)
Step3: Requirements specification (work product produced describing the function, performance, and
development constraints for a computer-based system)
Step4: System modeling (system representation that shows relationships among the system
components)
Step5: Requirements validation (examines the specification to ensure requirement quality and that
work products conform to agreed upon standards)
Step6: Requirements management (set of activities that help project team to identify, control, and
track requirements and changes as project proceeds)

Traceability Tables

Traceability is concerned with the relationships between requirements, their sources and the system
design

Features traceability table : Shows how requirements relate to important customer observable
system/product features.
Source traceability table: Identifies the source of each requirements.
Dependency traceability table: Indicates how requirements are related to one another.
Subsystem traceability table: Categorizes requirements by the subsystems that they govern.
Interface traceability table: Show how requirements relate to both internal and external system
interfaces.

Step2: Requirements Analysis

Software engineering task that bridges the gap between system level requirements engineering
and software design.
Provides software designer with a representation of system information, function, and behavior
that can be translated to data, architectural, and component-level designs.
Expect to do a little bit of design during analysis and a little bit of analysis during design.

Software Requirements Analysis Phases

Problem recognition System
Evaluation and synthesis Engineerin
(Focus is on what not how) g
Modeling
Specification Software
Review requirement
s
analysis
Software
design

Problems of requirements analysis
Stakeholders dont know what they really want
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting requirements
Organisational and political factors may influence the system requirements
The requirements change during the analysis process. New stakeholders may emerge and the
business environment change

Analysis Principles
The information domain of the problem must be represented and understood.
The functions that the software is to perform must be defined.
Software behavior must be represented.
Models depicting information, function, and behavior must be partitioned in a hierarchical
manner that uncovers detail.
The analysis process should move from the essential information toward implementation detail.

Further Readings...
Information Domain
Encompasses all data objects that contain numbers, text, images, audio, or video.
Information content or data model (shows the relationships among the data and control objects
that make up the system)
Information flow (represents the manner in which data and control objects change as each
moves through the system)
Information structure (representations of the internal organizations of various data and control
items)
Modeling
Data model (shows relationships among system objects)
Functional model (description of the functions that enable the transformations of system
objects)
Behavioral model (manner in which software responds to events from the outside world)

Partitioning
Process that results in the elaboration of data, function, or behavior.
Horizontal partitioning is a breadth-first decomposition of the system function, behavior, or
information, one level at a time.
Vertical partitioning is a depth-first elaboration of the system function, behavior, or information,
one sub-system at a time.

Software Requirements Views
Essential view - presents the functions to be accomplished and the information to be processed
without regard to implementation.
Implementation view - presents the real world manifestation of processing functions and
information structures.
Avoid the temptation to move directly to the implementation view, assuming that the essence of
the problem is obvious.

Requirements elicitation and analysis process
Sometimes called requirements elicitation or requirements discovery
Involves technical staff working with customers to find out about the application domain, the
services that the system should provide and the systems operational constraints
May involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.

Domain understanding
Requirements
Requirements collection definition and
Requirements specification
Classification validation
Conflict resolution
Prioritisation Domain
Prioritization
understanding
Requirements checking Process
entry

Requirements Conflict
collection resolution

Classification

View-point oriented methods
Stakeholders represent different ways of looking at a problem or problem viewpoints
This multi-perspective analysis is important as there is no single correct way to analyse system
requirements

Types of viewpoints
Data sources or sinks
o Viewpoints are responsible for producing or consuming data. Analysis involves checking
that data is produced and consumed and that assumptions about the source and sink of
data are valid

Representation frameworks
o Viewpoints represent particular types of system model. These may be compared to
discover requirements that would be missed using a single representation. Particularly
suitable for real-time systems

Receivers of services
o Viewpoints are external to the system and receive services from it. Most suited to
interactive systems
External viewpoints
Natural to think of end-users as receivers of system services
Viewpoints are a natural way to structure requirements elicitation
It is relatively easy to decide if a viewpoint is valid
Viewpoints and services may be sued to structure non-functional requirements

Methods based analysis

Widely used approach to requirements analysis. Depends on the application of a structured
method to understand the system
Methods have different emphases. Some are designed for requirements elicitation, others are
close to design methods
A viewpoint-oriented method (VORD) is used as an example here. It also illustrates the use of
viewpoints

VORD Method
The principle stages of the VORD method includes
Viewpoint identification
o Discover viewpoints which receive system services and identify the services provided to each
viewpoint
Viewpoint structuring
o Group related viewpoints into a hierarchy. Common services are provided at higher-levels in
the hierarchy
Viewpoint documentation
o Refine the description of the identified viewpoints and services
Viewpoint-system mapping
o Transform the analysis to an object-oriented design

Viewpoint Viewpoint Viewpoint Viewpoint
documentation
identification structuring system mapping

Fig: The VORD method
Step3: Software Requirement Specification
Specification Principles
Separate functionality from implementation.
Develop a behavioral model that describes functional responses to all system stimuli.
Define the environment in which the system operates and indicate how the collection of agents
will interact with it.
Create a cognitive model rather than an implementation model.

Recognize that the specification must be extensible and tolerant of incompleteness.
Establish the content and structure of a specification so that it can be changed easily.

Specification Representation
Representation format and content should be relevant to the problem.
Information contained within the specification should be nested.
Diagrams and other notational forms should be restricted in number and consistent in use.
Representations should be revisable.

Software Requirement specification
Produced at the culmination of the analysis task.
Functions and Performance are refined by establishing a complete information description, a
representation of system behavior, and indication of performance requirements and design
constraints, appropriate validation criteria, and other relevant information
Candidate format for software requirement specification:
Introduction
Information Description
Functional Description
Behavioral Description
Validation Criteria
Bibliography and Appendix

Specification Review
Conducted by customer and software developer.
Once approved, the specification becomes a contract for software development.
The specification is difficult to test in a meaningful way.
Assessing the impact of specification changes is hard to do.

Step5: Requirements validation
It shows the requirements actually define the system which the customer wants.
It checks for validity, consistency, completeness, realism, verifiability.
Requirements Validation techniques

1. Requirements reviews
Systematic manual analysis of the requirements
2. Prototyping
Using an executable model of the system to check requirements.
3. Test-case generation
Developing tests for requirements to check testability
4. Automated consistency analysis
Checking the consistency of a structured requirements description

1. Requirements reviews
Regular reviews should be held while the requirements definition is being formulated
Both client and contractor staff should be involved in reviews
Reviews may be formal (with completed documents) or informal. Good communications
between developers, customers and users can resolve problems at an early stage
It checks for Verifiability, Comprehensibility, Traceability and Adaptability.

2. Software Prototyping
Throwaway prototyping (prototype only used as a demonstration of product requirements,
finished software is engineered using another paradigm)
Evolutionary prototyping (prototype is refined to build the finished system)
Customer resources must be committed to evaluation and refinement of the prototype.
Customer must be capable of making requirements decisions in a timely manner.

Prototyping Methods and Tools

Fourth generation techniques (4GT tools allow software engineer to generate executable code quickly)
Reusable software components (assembling prototype from a set of existing software components)
Formal specification and prototyping environments (can interactively create executable programs from
software specification models)

3. Test case generation

Requirements should be testable. If the tests for the requirements are devised as part of the validation
process, this often reveals requirement problems. If a test is difficult or impossible to design, this usually
means that the requirements will be difficult to implement and should be reconsidered.

4. Automated consistency Analysis

If the requirements are expressed as a system model in a structured or formal notation the CASE tools
may be used to check the consistency of the model. To check the consistency, the CASE tool must build a
requirements database and then, using the rules of the method or notation, check all of the requirements
in this database.

Requirements Requirements
in a formal language problem report

Requirements Requirements
processor analyser

Requirements
database

Step6: Requirement Management
Requirements management is the process of managing changing requirements during the
requirements engineering process and system development
Requirements are inevitably incomplete and inconsistent
New requirements emerge during the process as business needs change and a better
understanding of the system is developed
Different viewpoints have different requirements and these are often contradictory
Requirement change because:
The priority of requirements from different viewpoints changes during the development
process
System customers may specify requirements from a business perspective that conflict
with end-user requirements
The business and technical environment of the system changes during its development

Principal stages consists of:
Problem analysis: Discuss requirements problem and propose change
Change analysis and costing: Assess effects of change on other requirements
Change implementation: Modify requirements document and other documents to reflect
change
Identified Revised
problem Problem analysis and requirements
Change analysis Change
change specification and costing implementation

Initial Change
understanding understanding
Of problem of problem

Initial Change
requirements requirements

Time

Fig: Requirement evolution
Enduring requirements: Stable requirements derived from the core activity of the customer
organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models

Volatile requirements: Requirements which change during development or when the system is in use.
In a hospital, requirements derived from health-care policy

Further Reading....
Q. Why is it so difficult to gain a clear understanding of what the customer wants?

A. It is because of the following problems that makes difficult to understand the customers wants:-
1. Problem of scope: The boundary of the system is ill-defined or the customer/users specify
unnecessary technical detail that may confuse, rather than clarify,
overall objectives.

2. Problem of understanding: The customers/users are not sure of what is needed, have a poor
understanding of the capabilities and limitations of their computing
environment, do not have a full understanding of the problem domain,
have trouble communicating needs to the system engineer, omit
information that is believed to be "obvious", specify requirements that
are ambiguous or un-testable.

3. Problem of volatility: The requirements change over time

Guideline for requirements elicitation

1. Access the business and technical feasibility for the proposed system.
2. Identify the people who will help specify requirements and understand their organizational bias.
3. Define the technical environment (e.g., computer architecture, operating system, telecommunications
needs) into which the system or product will be placed.
4. Identify "domain constraints" (i.e., characteristics of the business environment specific to the
application domain) that limit the functionality or performance of the system or product to be built.
5. Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).
6. Solicit participation from many people so that requirements are defined from different points of view;
be sure to identify the rationale for each requirement that is recorded.
7. Identify ambiguous requirements as candidates for prototyping. Creates usage scenario to help
customers/users better identify key requirements.

The work products produced as a consequence of the requirements elicitation activity should include:
1. A statement of need and feasibility
2. A bounded statement of scope for the system or product
3. A list of customers, users, and other stakeholders who participated in the requirements elicitation
activity.
4. A description of the system's technical environment.
5. A list of requirements (preferably organized by function) and the domain constraints that apply to
each.
6. A set of usage scenarios that provide insight into the use of the system or product under different
operating conditions.
7. Any prototypes developed to better define requirements.

Requirements Analysis Checklist

1. Is each requirement consistent with the overall objective for the system/product?
2. Have all requirements been specified at the proper level of abstraction? That is, do some requirements
provide a level of technical detail that is inappropriate at this stage?
3. Is the requirement really necessary or does it represent an add-on feature that may not be essential to
the objective of the system?
4. Is each requirement bounded and unambiguous?
5. Does each requirement have attribution? That is, a source (generally, a specific individual noted for
each requirements?
6. Do any requirements conflict with other requirements?
7. Is each requirement achievable in the technical environment that will house the system or product?
8. Is each requirement testable, once implemented?

Requirements validation checklist

Are requirements stated clearly? Can they be misinterpreted?
Is the source (e.g., a person, a regulation, a document) of the requirements
identified? Has the final statement of the requirements been examined by or against the original
source?
Is the requirement bounded in quantitative terms?
What other requirements relate to this requirement? Are they clearly noted via a cross-reference
matrix or other mechanism?
Does the requirement violate any domain constraints?
Is the requirement testable? If so, can we specify tests, ( validation criteria) to exercise the
requirement?
Is the requirement traceable to any system model that has been created?
Is the requirement traceable to overall system/product objectives?
Is the system specification structured in a way that leads to easy understanding, easy reference,
and easy translation into more technical work products?
Has an index for the specification been created?
Have requirements associated with system performance, behavior and operational
characteristics been clearly stated? What requirements appear to be implicit?

The requirements document
The requirements document is the official statement of what is required of the system
developers
Should include both a definition and a specification of requirements
It is NOT a design document. As far as possible, it should set of WHAT the system should do
rather than HOW it should do it

Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements

Use the requirements
document to plan a bid for
Managers
the system and to plan the
system development process

Use the requirements to
System engineers understand what system is to
be developed

System test Use the requirements to
engineers develop validation tests for
the system

Use the requirements to help
System
understand the system and
maintenance
the relationships between its
engineers
parts

IEEE requirements standard
This is a generic structure that must be instantiated for specific systems that includes:
Introduction
General description
Specific requirements
Appendices
Index

Requirements document structure
Introduction
Glossary
User requirements definition
System architecture
System requirements specification
System models
System evolution
Appendices
Index
MCA Software Engineering

Summary
Requirements analysis is the first technical step in the software process. In this phase, a general
statement of software scope is refined into a concrete specification that becomes the foundation for all
software engineering activities that follow.
Requirements set out what the system should do and define constraints on its operation and
implementation
Functional requirements set out services the system should provide
Non-functional requirements constrain the system being developed or the development process
User requirements are high-level statements of what the system should do
User requirements should be written in natural language, tables and diagrams
System requirements are intended to communicate the functions that the system should provide
System requirements may be written in structured natural language, a PDL or in a formal language
A software requirements document is an agreed statement of the system requirements
The requirements engineering process includes a feasibility study, requirements elicitation and
analysis, requirements specification and requirements management
Requirements analysis is iterative involving domain understanding, requirements collection,
classification, structuring, prioritisation and validation
Requirement analysis must focus on the information, functional, and behavioral domains of a problem.
To better understand what is required, models are created, the problem is partitioned, and
representations that depict the essence of requirements and, later, implementation details, are
developed.
Systems have multiple stakeholders with different requirements
Social and organisation factors influence system requirements
In many cases, it is not possible to completely specify a problem at an early stage. Prototyping offers
an alternative approach that results in an executable model of the software from which requirements
can be refined.
Software requirement specification is developed as a consequence of analysis. Review is essential to
ensure that the developer and the customer have the same perception of the system.
Requirements validation is concerned with checks for validity, consistency, completeness, realism and
verifiability
Business changes inevitably lead to changing requirements
Requirements management includes planning and change management


Assignments

Q1. Is it fair that a Preliminary user manual is a form of prototype? Explain.

Q2. Who should be involved in a requirements review? Draw a process model showing how a requirements
review might be organized?

Q3. When emergency changes have to be made to systems, the system software may have to be modified
before changes to the requirements have been approved. Suggest a model of a process for making these
modifications that ensure that the requirements document and the system implementation do not become
inconsistent.

Q4. Explain the term verification and validation

Q5. What do you mean by term Data-Dictionary in context of structured analysis? How is the Data Dictionary
useful in different phases of life cycle of a software product?
7. Software Validation
Software Testing Techniques-Overview

The importance of software testing to software quality cannot be overemphasized. Software testing is a
critical element of software quality assurance and represents the ultimate review of specification, design, and
code generation. Once source code has been generated, software must be tested to allow errors to be
identified and removed before delivery to the customer. While it is not possible to remove every error in a
large software package, the software engineers goal is to remove as many as possible early in the software
development cycle. It is important to remember that testing can only find errors, it cannot prove that a
program is bug free. . The greater visibility of software systems and the cost associated with software failure
are motivating factors for planning, through testing. It is not uncommon for a software organization to spent
40% of its effort on testing. Two basic test techniques involve testing module input/output (black-box) and
exercising internal logic of software components (white-box). Formal technical reviews by themselves can not
find allow software defects, test data must also be used. For large software projects, separate test teams may
be used to develop and execute the set of test cases used in testing. Testing must be planned and designed.

The following are some commonly used terms associated with testing:

A failure is a manifestation of an error (or defect or bug). But, the mere presence of an error may not
necessarily lead to a failure.

A fault is an incorrect intermediate state that may have been entered during program execution, e.g., a
variable value is different from what it should be. A fault may or may not lead to a failure.

A test data is the inputs which have been devised to test the system.

A test case is the triplet [I,S,O], where I is the data input to the system, S is the state of the system at which
data is input, and O is the expected output of the system or Inputs to test the system and the predicted outputs
from these inputs if the system operates according to its specification

During testing the software engineering produces a series of test cases that are used to rip apart the
software they have produced. Testing is the one step in the software process that can be seen by the
developer as destructive instead of constructive. Software engineers are typically constructive people and
testing requires them to overcome preconceived concepts of correctness and deal with conflicts when errors
are identified.

No single type of test provides enough information to quantify the quality of a system. Instead, multiple types
of testing must be undertaken to fully ascertain a software application's quality. However, it says that " You
cant test in quality. If its not there before you begin testing, it wont be there when youre finished testing."

Software Testing Objectives
Testing is the process of executing a program with the intent of finding errors.
A good test case is one with a high probability of finding an as-yet undiscovered error.
A successful test is one that discovers an as-yet-undiscovered error.

Test information flow
Information flow for testing follows the pattern shown in the figure below. Two types of input are given to the
test process: (1) a software configuration; (2) a test configuration. Tests are performed and all outcomes
considered, test results are compared with expected results. When erroneous data is identified error is
implied and debugging begins. The debugging procedure is the most unpredictable element of the testing
procedure. An error that indicates a discrepancy of 0.01 percent between the expected and the actual
results can take hours, days or months to identify and correct. It is the uncertainty in debugging that causes
testing to be difficult to schedule reliability.
Test information flow
Software
Evaluation
configuration Errors
Test Results
Debug
Testing Error rate
data
Corrections
Test configuration Expected results
Reliability
Model
Predicted
reliability

Software Testing Principles
All tests should be traceable to customer requirements.
Tests should be planned long before testing begins.
The Pareto principle (80% of all errors will likely be found in 20% of the code) applies to software
testing.
Testing should begin in the small and progress to the large.
Exhaustive testing is not possible.
To be most effective, testing should be conducted by an independent third party.

Software Testability Checklist
Operability- the better it works the more efficiently it can be tested
Observability- what you see is what you test
Controllability- the better software can be controlled the more testing can be automated and optimized
Decomposability- by controlling the scope of testing, the more quickly problems can be isolated and
retested intelligently
Simplicity- the less there is to test, the more quickly we can test
Stability- the fewer the changes, the fewer the disruptions to testing
Understandability-the more information known, the smarter the testing

Good Test Attributes

A good test has a high probability of finding an error.
A good test is not redundant.
A good test should be best of breed.
A good test should not be too simple or too complex.

Software Testing Process

Unit
testing
Module
testing

Sub-system
testing
System
testing
Acceptance
testing

Component Integration testing User
testing testing

Unit testing - Individual components are tested independently, without other system components
Module testing - Related collections of dependent components( class, ADT, procedures & functions)
are tested, without other system module.
Sub-system testing-Modules are integrated into sub-systems and tested. The focus here should be on
interface testing to detect module interface errors or mismatches.
System testing - Testing of the system as a whole. Validating functional and non-functional
requirements & Testing of emergent system properties.
Acceptance testing-Testing with customer data to check that it is acceptable. Also called Alpha Testing.
Making sure the software works correctly for intended user in his or her normal work
environment.
Alpha test-version of the complete software is tested by customer under the supervision of the
developer at the developers site.
Beta test-version of the complete software is tested by customer at his or her own site without
the developer being present

Component testing
Testing of individual program components.
Usually the responsibility of the component developer (except sometimes for critical systems).
Tests are derived from the developers experience.

Integration testing
Testing of groups of components integrated to create a system or sub-system.
The responsibility of an independent testing team.
Tests are based on a system specification.

Testing Phases

Requirements System System Detailed
specification specification design design

Acceptance
System Sub-system Module and
integration integration unit code
test plan
test plan test plan and tess

Acceptance System Sub-system
Service
test integration test integration test

Fig: Software Testing phases
Test case design
The design of software testing can be a challenging process. However software engineers often see testing as
an afterthought, producing test cases that feel right but have little assurance that they are complete. The
primary objective of testing is to have the highest likelihood of finding the most errors with a minimum amount of
timing and effort. A large number of test case design methods have been developed that offer the developer
with a systematic approach to testing. Methods offer an approach that can ensure the completeness of tests
and offer the highest likelihood for uncovering errors in software.

Any engineering product can be tested in two ways: (1) Knowing the specified functions that the product has
been designed to perform, tests can be performed that show that each function is fully operational (2)
knowing the internal workings of a product, tests can be performed to see if they jell. The first test approach
is known as a black box testing and the second white box testing.

Black box testing relates to the tests that are performed at the software interface. Although they are designed
identify errors, black box tests are used to demonstrate that software functions are operational; that inputs
are correctly accepted and the output is correctly produced. A black box test considers elements of the system
with little interest in the internal logical arrangement of the software. White box testing of software involves
a closer examination of procedural detail. Logical paths through the software are considered by providing test
cases that exercise particular sets of conditions and/or loops. The status of the system can be identified at
diverse points to establish if the expected status matches the actual status.

Test Case Design Strategies
Black-box or behavioral testing
White-box or glass-box testing

Black Box testing

Also known as Behavioral or Functional testing.
The system is a " Black-box" whose behavior is determined by studying its input and related the
outputs.
It is techniques of knowing the specified function a product is to perform and demonstrating correct
operation based solely on its specification without regard for its internal logic.
Focus on the functional requirements of the software i.e., information domain not the implementation
part of the software.
Different categories of errors include incorrect or missing functions, interface error, errors in data
structures or external database access, behavior or performance errors, and initiation and termination
errors.
It is performed during later stages of testing process, like in the acceptance testing or beta testing.
Test are designed to answer the following questions:
o How is functional validity tested?
o How is system behavior and performance tested?
o What classes of input behavior will make good test case?
o Is the system particularly sensitive to certain input values?
o How are the boundaries of data class isolated?
o What data rates and data volume can the system tolerate?
o What effect will specific combinations of data have on system operations?

Techniques include Equivalence Partitioning, Boundary Value Analysis, Comparison Testing, and
Orthogonal Array Testing.

Advantages:
o Validates whether or not a given system conforms to its software specification
o Introduce a series of inputs to a system and compare the outputs to a pre-defined test
specification.
o Test integration between individual system components.
o Tests are architecture independent they do not concern themselves with how a given
output is produced, only with whether that output is the desired and expected output.
o Require no knowledge of the underlying system, one need not be a software engineer to design
black box tests.

Disadvantages:
o Offer no guarantee that every line of code has been tested.
o Being architecture independent, it cannot determine the efficiency of the code.
o Will not find any errors, such as memory leaks, that are not explicitly and instantly exposed by
the application.
Inputs causing
anomalous
Input test data I behaviour
e

System

Outputs which reveal
the presence of
Output test results Oe defects

Fig: Black box testing

White-box testing
Also known as Structural or Glass-box testing.
Knowing the internal workings of a product, tests are performed to check the workings of all
independent logic paths.
It uses the control structure of the procedural design to derive test cases that:
o Guarantee that all independent paths within a module have been exercised at least once.
o Exercise all logical decisions on their true and false sides.
o Execute all loops at their boundaries and within their operational bounds
o Exercise internal data structures to ensure their validity
Derivation of test cases according to program structure. Knowledge of the program is used to identify
additional test cases
Objective is to exercise all program statements (not all path combinations)
Techniques being used: basic path and control structure testing.

Test data

Tests Derives

Component Test
code outputs

Fig: Structural testing or while box testing


Difference between Black box testing and White-box testing

Black-box testing White-box testing
Also referred as Function testing as it test the Also referred as Structural testing as it checks the
functionality of the system workings of all independent logic paths.
Also known as behavioral testing as system Also known as glass-box testing as its internal
behavior is determined by studying its input and coding part should be tested and verified.
related the outputs.
Called " testing in the large" Called " testing in the small" as applied to small
program components.
Knowledge of internal program logic is not Knowledge of internal program logic is an essential
important.
Objective is to check it meets the user Objective is to check all program statement as per
requirements as per the specification documents. the design specification.
Discover faults of omission, indicating that part of Discover faults of commission, indicating that part
the specification has not been fulfilled. of the implementation is faulty.
Mostly performed by the user's side. Mostly performed by the programmer's side
Back-box testing is done at the later stage of the While-box testing is done at the earlier stage of the
SWSDLC. SWDLC.
Performed as per the acceptance test plan. Performed as per the Component and Integration
test plan.
Techniques include Equivalence Partitioning, Techniques include basic path and control
Boundary Value Analysis, Comparison Testing, and structure testing
Orthogonal Array Testing.
Errors include incorrect or missing functions, Errors include logical errors in the coding
interface error, errors in data structures or statement and typing error.
external database access, behavior or performance
errors, and initiation and termination errors.

Basis Path Testing
White-box technique usually based on the program flow graph. It derives logical complexity measures
of a procedural design for defining a basis set of execution paths.
Test cases produced to exercise each statement in the program at least one time during testing.
The cyclomatic complexity of the program computed from its flow graph using the formula V(G) = E N
+ 2 or by counting the conditional statements in the PDL representation and adding 1
Determine the basis set of linearly independent paths (the cardinality of this set id the program
cyclomatic complexity)
Prepare test cases that will force the execution of each path in the basis set.
Flow graph notation
The flow graph can be used to represent the logical flow control and therefore all the execution paths that
need testing. To illustrate the use of flow graphs consider the procedural design depicted in the flow chart
below. This is mapped into the flow graph below where the circles are nodes that represent one or more
procedural statements and the arrow in the flow graph called edges represent the flow control. Each node
that includes a condition is known as a predicate node, and has two or more edges coming from it.
Sequence If Case
While Until
Each circle represents one or more non-branching PDL or source code statements

Fig: Flow graph Notation

1

2

3

6 4

5
7 8
9

10

11
Fig: Flow Chart

1
Node

Edges

2,3
Predicat
e Node

6

7 8 4,5

9

Region
10

11

Fig: Flow graph
Control Structure Testing
White-box techniques focusing on control structures present in the software
Condition testing (e.g. branch testing) focuses on testing each decision statement in a software
module, it is important to ensure coverage of all logical combinations of data that may be processed by
the module (a truth table may be helpful)
Data flow testing selects test paths based according to the locations of variable definitions and uses in
the program (e.g. definition use chains)
Loop testing focuses on the validity of the program loop constructs (i.e. simple loops, concatenated
loops, nested loops, unstructured loops), involves checking to ensure loops start and stop when they
are supposed to (unstructured loops should be redesigned whenever possible)

Graph-based Testing Methods

Black-box methods based on the nature of the relationships (links) among the program objects
(nodes), test cases are designed to traverse the entire graph
Transaction flow testing (nodes represent steps in some transaction and links represent logical
connections between steps that need to be validated)
Finite state modeling (nodes represent user observable states of the software and links represent
transitions between states)
Data flow modeling (nodes are data objects and links are transformations from one data object to
another)
Timing modeling (nodes are program objects and links are sequential connections between these
objects, link weights are required execution times)

Equivalence Partitioning
Black-box technique that divides the input domain into classes of data from which test cases can be
derived
Input data and output results often fall into different classes where all members of a class are related
An ideal test case uncovers a class of errors that might require many arbitrary test cases to be
executed before a general error is observed
Each of these classes is an equivalence partition where the program behaves in an equivalent way for
each class member
Test cases should be chosen from each partition
Equivalence class guidelines:
o If input condition specifies a range, one valid and two invalid equivalence classes are defined
o If an input condition requires a specific value, one valid and two invalid equivalence classes are
defined
o If an input condition specifies a member of a set, one valid and one invalid equivalence class is
defined
o If an input condition is Boolean, one valid and one invalid equivalence class is defined

Partition system inputs and outputs into
equivalence sets
If input is a 5-digit integer between 10,000
and 99,999, Invalid inputs Valid inputs
equivalence partitions are <10,000, 10,000-99,
999 and >
10, 000
System
Choose test cases at the boundary of these sets
00000, 09999, 10000, 99999, 10001
Outputs

3 11
4 7 10

Less than 4 Between 4 and 10 More than 10

Number of input values

9999 100000
10000 50000 99999

Less than 10000 Between 10000 and 99999 More than 99999

Input values

Boundary Value Analysis
Black-box technique that focuses on the boundaries of the input domain rather than its center
BVA guidelines:
o If input condition specifies a range bounded by values a and b, test cases should include a and
b, values just above and just below a and b
o If an input condition specifies and number of values, test cases should be exercise the
minimum and maximum numbers, as well as values just above and just below the minimum
and maximum values
o Apply guidelines 1 and 2 to output conditions, test cases should be designed to produce the
minimum and maxim output reports
o If internal program data structures have boundaries (e.g. size limitations), be certain to test the
boundaries

Comparison Testing
Black-box testing for safety critical systems in which independently developed implementations of
redundant systems are tested for conformance to specifications
Often equivalence class partitioning is used to develop a common set of test cases for each
implementation.

Orthogonal Array Testing
Black-box technique that enables the design of a reasonably small set of test cases that provide
maximum test coverage
Focus is on categories of faulty logic likely to be present in the software component (without
examining the code)
Priorities for assessing tests using an orthogonal array
o Detect and isolate all single mode faults
o Detect all double mode faults
o Multimode faults

Specialized Testing
It encompasses a broad array of software capabilities and application areas.
Graphical user interfaces
Client/server architectures
Documentation and help facilities
Real-time systems
o Task testing (test each time dependent task independently)
o Behavioral testing (simulate system response to external events)
o Intertask testing (check communications errors among tasks)
o System testing (check interaction of integrated system software and hardware)

Software Testing Strategies-Overview
A strategy for software testing integrates software test case design methods into a well-planned series of steps
that result in the successful construction of software. Software testing must be planned carefully to avoid
wasting development time and resources. Testing begins "in the small" and progresses "to the large". Initially
individual components are tested using white box and black box techniques. After the individual components
have been tested and added to the system, integration testing takes place. Once the full software product is
completed, system testing is performed. The Test Specification document should be reviewed like all other
software engineering work products.

Strategic Approach to Software Testing
Testing is a set of activities that can be planned in advance and conducted systematically. Software testing
strategy should have the following characteristics:
Testing begins at the component level and works outward toward the integration of the entire
computer-based system.
Different testing techniques are appropriate at different points in time.
The developer of the software conducts testing and may be assisted by independent test groups for
large projects.
The role of the independent tester is to remove the conflict of interest inherent when the builder is
testing his or her own product.
Testing and debugging are different activities.
Debugging must be accommodated in any testing strategy.
Make a distinction between verification and validation.

Distinction between Verification and Validation
Software testing is one type of a broader domain that is known as verification and validation (V&V).
Verification and validation is intended to show that a system conforms to its specification and meets the
requirements of the system customer. It involves checking and review processes and system testing. The
following table shows the distinction between verification and validation.

Verification Validation
A set of operations that the software correctly a different set of activities that ensures that the
implements a particular function. software that has been produced is traceable to
customer real needs.
Software verification is achieved through a series Software validation is achieved through a series of
of while box tests that shows conformity to its black box tests that show conformity with
design and statement of codes. requirements.
Ensure the correct implementation of a specific Ensure that the software that has been built is
function. traceable to customer requirements.

It focuses on "are we building the product right?" It focuses on "are we building the right product?"
It is performed at the each and every stages of the It is performed at the later stages of the software
software coding like unit, module and subsystem development like system testing, acceptance
testing. testing.

Strategic Testing Issues

Specify product requirements in a quantifiable manner before testing starts.
Specify testing objectives explicitly.
Identify the user classes of the software and develop a profile for each.
Develop a test plan that emphasizes rapid cycle testing.
Build robust software that is designed to test itself (e.g. uses anti-bugging).
Use effective formal reviews as a filter prior to testing.
Conduct formal technical reviews to assess the test strategy and test cases.

Software Testing Plan

Preparation and planning for the test phase should begin early in the development cycle and be a constant
concern throughout the development process.
Test Plan Test Code Validate Run Test

Specification Tests Tests

Fig: Test development cycle

The structure of a software-testing plan includes:

The testing process: A description of the major phases of the testing process.

Requirements traceability: It describes the system meeting users requirements and testing should be
planned so that all requirements are individually tested.

Tested items: Specify the product of the software process to be tested.

Test recording procedures: Recording the tests results systematically and auditing the testing process to
check that it has been carried out correctly.

Hardware and Software requirements: Set out software tools required and estimated hardware utilization.

Constraints: Specify the constraints affecting the testing process such as staff shortages.

Unit Testing
Black box and white box testing.
Unit testing concentrates verification on the smallest element of the the module
Module interfaces are tested for proper information flow.
Local data are examined to ensure that integrity is maintained.
Boundary conditions are tested.
Basis path testing should be used.
All error handling paths should be tested.
Drivers and/or stubs need to be developed to test incomplete software.

Unit test considerations
The tests that are performed as part of unit testing are shown in the figure below. The module interface is
tested to ensure that information properly flows into and out of the program unit being tested. The local data
structure is considered to ensure that data stored temporarily maintains its integrity for all stages in an
algorithms execution. Boundary conditions are tested to ensure that the modules perform correctly at
boundaries created to limit or restrict processing. All independent paths through the control structure are
exercised to ensure that all statements in been executed once. Finally, all error-handling paths are examined.

Interface
Module Local data structures
Boundary Conditions
Independent paths
Error-handling paths

Test cases

Fig: Unit test

Unit test procedures
Unit testing is typically seen as an adjunct to the coding step. Once source code has been produced, reviewed,
and verified for correct syntax, unit test case design can start. A review of design information offers assistance
for determining test cases that should uncover errors. Each test case should be linked with a set of anticipated
results. As a module is not a stand-alone program, driver and/stub software must be produced for each test
units. In most situations a driver is a main program that receives test case data, passes this to the module
being tested and prints the results. Stubs act as the sub-modules called by the test modules. Unit testing is
made easy if a module has cohesion.

Integration Testing

Top-down integration testing
o Start with high-level system and integrate from the top-down replacing individual components by
stubs where appropriate
o Main control module used as a test driver and stubs are substitutes for components directly
subordinate to it.
o Subordinate stubs are replaced one at a time with real components (following the depth-first or
breadth-first approach).
o Tests are conducted as each component is integrated.
o On completion of each set of tests and other stub is replaced with a real component.
o Regression testing may be used to ensure that new errors not introduced.
Testing
Level 1 Level 1 ...
sequence
Level 2 Level 2 Level 2 Level 2
Level 2
stubs
Level 3
stubs

The integration process is performed in a series of five stages:

1. The main control module is used as a test driver and stubs are substituted for all modules directly
subordinate to the main control module.
2. Depending on the integration technique chosen, subordinate stubs are replaced one at a time with
actual modules.
3. Tests are conducted as each module is integrated.
4. On the completion of each group of tests, another stub is replaced with the real module.
5. Regression testing may be performed to ensure that new errors have been introduced.

Bottom-up integration testing
o Integrate individual components in levels until the complete system is created
o Low level components are combined in clusters that perform a specific software function.
o A driver (control program) is written to coordinate test case input and output.
o The cluster is tested.
o Drivers are removed and clusters are combined moving upward in the program structure.
o Regression testing (check for defects propagated to other modules by changes made to existing
program)
o Representative sample of existing test cases is used to exercise all software functions.
o Additional test cases focusing software functions likely to be affected by the change.
o Tests cases that focus on the changed software components.


Test

drivers
Testing
Level N Level N Level N Level N Level N
sequence

Test
drivers
Level N1 Level N1 Level N1

A bottom-up integration strategy may be implemented with the following steps:

1. Low-level modules are combined into clusters that perform a particular software subfunction.
2. A driver is written to coordinate test cases input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward in the program structure.

Comments on Integration Testing
There has been much discussion on the advantages and disadvantages of bottom-up and top-down integration
testing. Typically a disadvantage of one is an advantage of the other approach. The major disadvantage of
top-down approaches is the need for stubs and the difficulties that are linked with them. Problems linked
with stubs may be offset by the advantage of testing major control functions early. The major drawback of
bottom-up integration is that the program does not exist until the last module is included.

Smoke testing
Software components already translated into code are integrated into a build.
A series of tests designed to expose errors that will keep the build from performing its functions are
created.
The build is integrated with the other builds and the entire product is smoke tested daily (either top-
down or bottom integration may be used).

General Software Test Criteria
Interface integrity (internal and external module interfaces are tested as each module or cluster is
added to the software)
Functional validity (test to uncover functional defects in the software)
Information content (test for errors in local or global data structures)
Performance (verify specified performance bounds are tested)

Validation Testing

Ensure that each function or performance characteristic conforms to its specification.
Deviations (deficiencies) must be negotiated with the customer to establish a means for resolving the
errors.
Configuration review or audit is used to ensure that all elements of the software configuration have
been properly developed, cataloged, and documented to allow its support during its maintenance
phase.
Validation test criteria- Software validation is achieved through a series of black box tests that show
conformity with requirements. A test plan provides the classes of tests to be performed and a test
procedure sets out particular test cases that are to be used to show conformity with requirements.

Acceptance Testing
Making sure the software works correctly for intended user in his or her normal work environment.
Alpha test (version of the complete software is tested by customer under the supervision of the
developer at the developers site)
Beta test (version of the complete software is tested by customer at his or her own site without the
developer being present)

System Testing
Recovery testing (checks the systems ability to recover from failures)
Security testing (verifies that system protection mechanism prevent improper penetration or data
alteration)
Stress testing (program is checked to see how well it deals with abnormal resource demands
quantity, frequency, or volume)
Performance testing (designed to test the run-time performance of software, especially real-time
software)

Debugging
1. Debugging (removal of a defect) occurs as a consequence of successful testing.
2. Testing establishes the existence of defects where as debugging is concerned with locating and
correcting these defects
3. Common approaches:
1. Brute force (memory dumps and run-time traces are examined for clues to error causes)
2. Backtracking (source code is examined by looking backwards from symptom to potential
causes of errors)
3. Cause elimination (uses binary partitioning to reduce the number of locations potential where
errors can exist)

Debugging Process
Figure illustrates a possible debugging process. Defects in the code must be located and the program modified
to meet its requirements. Testing must then be repeated to ensure that the change has been made correctly.
Thus debugging process is a part of both software development and software testing.

Test Results Specificatio Test Cases
n

Locate Design Repair Re-test

error error repair error program

Fig: debugging process

Bug Removal Considerations

Is the cause of the bug reproduced in another part of the program?
What "next bug" might be introduced by the fix that is being proposed?
What could have been done to prevent this bug in the first place?
Refer Slide: MCA_SE_Chapter_07_Software_Validation.pps

TEST SPECIFICATION DOCUMENT

1.0 Introduction
This section provides an overview of the entire test document. This document describes both the test plan and
the test procedure.
1.1 Goals and objectives
Overall goals and objectives of the test process are described.
1.2 Statement of scope
A description of the scope of software testing is developed. Functionality/features/behavior to be
tested is noted. In addition any functionality/features/behavior that is not to be tested is also noted.

1.3 Major constraints
Any business, product line or technical constraints that will impact the manner in which the software
is to be tested are noted here.

2.0 Test Plan
This section describes the overall testing strategy and the project management issues that are required to
properly execute effective tests.

2.1 Software (SCIs) to be tested
The software to be tested is identified by name. Exclusions are noted explicitly.
2.2 Testing strategy
The overall strategy for software testing is described.
2.2.1 Unit testing
The strategy for unit tested is described. This includes an indication of the components that will
undergo unit tests or the criteria to be used to select components for unit test. Test cases are NOT
included here.
2.2.2 Integration testing
The integration testing strategy is specified. This section includes a discussion of the order of
integration by software function. Test cases are NOT included here.
2.2.3 Validation testing
The validation testing strategy is specified. This section includes a discussion of the order of validation
by software function. Test cases are NOT included here.
2.2.4 High-order testing
The high-order testing strategy is specified. This section includes a discussion of the types of high
order tests to be conducted, the responsibility for those tests. Test cases are NOT included here.
2.3 Testing resources and staffing
Specialized testing resources are described and staffing is defined. The role of any ITG is also defined.
2.4 Test work products
The work products produced as a consequence of the testing strategy are identified.
2.5 Test record keeping
Mechanisms for storing and evaluating test results are specified.
2.6 Test metrics
A description of all test metrics to be used during the testing activity is noted here.
2.7 Testing tools and environment
A description of the test environment, including tools, simulators, specialized hardware, test files, and
other resource is presented here.
2.8 Test schedule
A detailed schedule for unit, integration, and validation testing as well as high order tests is described.

3.0 Test Procedure
This section describes as detailed test procedure including test tactics and test cases for the software.
3.1 Software (SCIs) to be tested
The software to be tested is identified by name. Exclusions are noted explicitly.
3.2 Testing procedure
The overall procedure for software testing is described.
3.2.1 Unit test cases
The procedure for unit testing is described for each software component (that will be unit tested) is
presented. This section is repeated for all components).
3.2.1.2 Stubs and/or drivers for component i
3.2.1.3 Test cases component i
3.2.1.4 Purpose of tests for component i
3.2.1.5 Expected results for component i
3.2.2 Integration testing: The integration testing procedure is specified.
3.2.2.1 Testing procedure for integration
3.2.2.2 Stubs and drivers required
3.2.2.3 Test cases and their purpose
3.2.2.4 Expected results
3.2.3 Validation testing: The validation testing procedure is specified.
3.2.3.1 Testing procedure for validation
3.2.3.3 Expected results
3.2.3.4 Pass/fail criterion for all validation tests
3.2.4 High-order testing (a.k.a. System Testing)
The high-order testing procedure is specified. For each of the high order tests specified below, the test
procedure, test cases, purpose, specialized requirements and pass/fail criteria are specified. It should
be noted that not all high-order test methods noted in Sections 3.2.4.n will be conducted for every
project.
3.2.4.1 Recovery testing
3.2.4.2 Security testing
3.2.4.3 Stress testing
3.2.4.4 Performance testing
3.2.4.5 Alpha/beta testing
3.2.4.6 Pass/fail criterion for all validation tests
3.3 Testing resources and staffing
Specialized testing resources are described and staffing is defined. The role of any ITG is also defined.
3.4 Test work products
The work products produced as a consequence of the testing procedure are identified.
3.5 Test record keeping and test log
Mechanisms for storing and evaluating test results are specified. The test log is used to maintain a
chronological record of all tests and their results.

Summary

It is more important to test the parts of the system which are commonly used rather than parts which are
only rarely exercised.

Equivalent partitioning is way of deriving test cases. It depends on finding partitions in the input and
output data sets and exercising the program with values from these partitions. Often, the value which is
most likely to lead to a successful test is a value at the boundary of a partition.

Black-box testing does not need access to source code. Test cases are derived from the program
specification.

Structural testing relies on a analyzing a program to determine paths through it and using this analysis to
assist with the selection of test cases.

Integration testing should focus on testing the interactions between the components in a system and
component interfaces.

Interface defects may arise because of errors made in reading the specification, specification
misunderstandings or errors or invalid timing assumptions. Interface testing is intended to discover
defects in the interfaces of objects or modules.

When testing object classes, you should design tests that exercise all of the operations associated with a
class, assign and evaluate all object attributes and test the object in all possible states.

Object oriented systems should be integrated around natural clusters of objects such as those associated
with a particular use-cases or with object threads.

Assignments Questions

1) Discuss the difference between black box and structural testing and suggest how they can be used
together in the defect testing process.

2) Show, using a small example, why it is practically impossible to exhaustively test a program.

3) Explain why interface testing is necessary given that individual units have been extensively validated
through unit testing and program inspections.

4) Explain why bottom-up and top-down testing may be inappropriate testing strategies for object-oriented
systems.

5) What is black box testing? Explain the advantages and disadvantages of back-box testing.

6) Why White-box testing is called Glass-box testing? Explain the flow graph-notation

8. Software Evolution

SELF STUDY

Software Project Management
Overview
Project management involves the planning, monitoring, and control of people, process, and events that
occur during software development.
It is concerned with activities involved in ensuring that software is delivered on time and on schedule and
in accordance with the requirements of the organisations developing and procuring the software.
Project management is needed because software development is always subject to budget and
schedule constraints that are set by the organisation developing the software
Everyone manages, but the scope of each person's management activities varies according his or her
role in the project.
Software needs to be managed because it is a complex undertaking with a long duration time.
Managers must focus on the fours P's to be successful (people, product, process, and project) i.e., it
defines the process and task to be conducted, the people who will do the work, and the mechanisms
for assessing risks, controlling change and evaluating quality.
A project plan is a document that defines the four P's in such a way as to ensure a cost effective, high
quality software product. i.e., it defines the process and tasks to be conducted, the people who will do
the work, and the mechanisms for assessing risks, controlling change and evaluating quality.
The only way to be sure that a project plan worked correctly is by observing that a high quality
product was delivered on time and under budget.

Project management is the Organising, planning and scheduling software projects

Management Spectrum
People (The PM-CMM's Key practice areas includes recruiting, selection, performance management,
training, compensation, career development, organization, work design, team/culture development)
Product (product objectives, scope, alternative solutions, constraint tradeoffs)
Process (framework activities populated with tasks, milestones, work products, and QA points)
Project (planning, monitoring, controlling)

People
Players (senior managers, technical managers, practitioners, customers, end-users)
Team leadership model (motivation, organization, skills)
Characteristics of effective project managers (problem solving, managerial identity, achievement,
influence and team building)


Note: People Management- Capability Maturity Model (PM-CMM) enhance the readiness of software
organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and
retain the talent needed to improve their software development capability. PM-CMM is a companion to the
software capability maturity model that guides organizations in the creation of a mature software process.

Software Team Organization
Democratic decentralized (rotating task coordinators and group consensus)
Controlled decentralized (permanent leader, group problem solving, subgroup implementation of
solutions)
Controlled centralized (top level problem solving and internal coordination managed by team leader)

Factors Affecting Team Organization
Difficulty of problem to be solved
Size of resulting program
Team lifetime
Degree to which problem can be modularized
Required quality and reliability of the system to be built
Rigidity of the delivery date
Degree of communication required for the project
Coordination and Communication Issues
Formal, impersonal approaches (e.g. documents, milestones, memos)
Formal interpersonal approaches (e.g. review meetings, inspections)
Informal interpersonal approaches (e.g. information meetings, problem solving)
Electronic communication (e.g. e-mail, bulletin boards, video conferencing)
Interpersonal network (e.g. informal discussion with people other than project team members)

The Product
Software scope (context, information objectives, function, performance)
Problem decomposition (partitioning or problem elaboration - focus is on functionality to be delivered
and the process used to deliver it)
The Process
Process model chosen must be appropriate for the: customers and developers, characteristics of the
product, and project development environment
Project planning begins with melding the product and the process
Each function to be engineered must pass though the set of framework activities defined for a software
organization
Work tasks may vary but the common process framework (CPF) is invariant (project size does not
change the CPF)
The job of the software engineer is to estimate the resources required to move each function though
the framework activities to produce each work product
Project decomposition begins when the project manager tries to determine how to accomplish each
CPF activity

The Project
Five-part common sense approach to software project includes:
Start on the right foot
Maintain momentum
Track progress
Make smart decisions
Conduct a postmortem analysis

W5HH Principle
Why is the system being developed?
What will be done by when?
Who is responsible for a function?
Where are they organizationally located?
How will the job be done technically and managerially?
How much of each resource is needed?

Critical Practices
Formal risk management
Empirical cost and schedule estimation
Metric-based project management
Earned value tracking
Defect tracking against quality targets
People-aware program management


Summary
Software project management is an umbrella activity within software engineering. It begins before any
technical activity is initiated and continues throughout the definition, development, and support of computer
software.

Four P's have a substantial influence on the software project management-people, product, process, and
project. People must be organized into effective teams, motivated to do high-quality software work, and
coordinated to achieve effective communication. The product requirements must be communicated from
customer to developer, partitioned (decomposed) into their constituent parts, and positioned for work by the
software team. The process must be adapted to the people and the problem. A common process framework
(CPF) is selected, an appropriate software engineering paradigm is applied, and a set of work tasks is chosen
to get the job done. Finally, the project must be organized in a manner that enables the software team to
succeed. The project management activity encompasses measurement and metrics, estimation, risk analysis,
schedules, tracking, and control.

Software Project Planning-Overview
Software planning involves estimating how much time, effort, money, and resources will be required to build a
specific software system. After the project scope is determined and the problem is decomposed into smaller
problems, software managers use historical project data (as well as personal experience and intuition) to
determine estimates for each. The final estimates are typically adjusted by taking project complexity and risk
into account. The resulting work product is called a project management plan.

Probably the most time-consuming project management activity
Continuous activity from initial concept through to system delivery. Plans must be regularly revised as
new information becomes available
Various different types of plan may be developed to support the main software project plan that is
concerned with schedule and budget

Project Planning Objectives
To provide a framework that enables software manager to make a reasonable estimate of resources,
cost, and schedule.
Project outcomes should be bounded by 'best case' and 'worst case' scenarios.
Estimates should be updated as the project progresses.


Types of Project Plan
Plan Description
Quality Plan Describes the quality procedures and standards that will be
used in a project.
Validation Plan Describes the approach, resources and schedules used for
system validation.
Confirmation management Plan describes the configuration management procedures and
structures and structures to be used.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance cost, and effort required.
Staff development plan Describes how the skills and experience of the project team
members will be developed.

Project Planning Process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while)
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if (problems arise) then
Initiate technical review and possible revision
end if
end loop


Project Plan Structure
Introduction
Project organisation
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Monitoring and reporting mechanisms

Estimation Reliability Factors
Project complexity
Project size
Degree of structural uncertainty (degree to which requirements have solidified, the ease with which
functions can be compartmentalized, and the hierarchical nature of the information processed)
Availability of historical information

Software Project Planning activities
Step1: Determination of software scope and feasibility study
Step2: Estimation of the resources

Step1: Determination of software scope
Describes the data to be processed and produced, control parameters, function, performance (wrt
processing and response time requirement), constraints ( wrt limits placed on the software by
external hardware, available memory, or other existing system), external interfaces, and reliability.
Often functions described in the software scope statement are refined to allow for better estimates of
cost and schedule.

Customer Communication and Scope
Necessary information is obtained by conducting a preliminary meeting or interview with customer, where
Analyst prepare a set of context free questions in order to....
Determine the customer's overall goals for the proposed system and any expected benefits.
Determine the customer's perceptions concerning the nature if a good solution to the problem.
Evaluate the effectiveness of the customer meeting.

FAST (Facilitated Application Specification Techniques)
It is a team-oriented approach to requirement gathering that can be applied to help establish the scope of a
project. It encourages the creation of a joint team of customer and development who work together to identify
the problem, propose elements of the solution, negotiate different approaches & specify a preliminary set of
requirements.

Feasibility Study
Technical feasibility is not a good enough reason to build a product.
The product must meet the customer's needs and not be available as an off-the-shelf purchase.
Step 2: Estimation of Resources
Human Resources (number of people required and skills needed to complete the development project)
Reusable Software Resources (off-the-shelf components, full-experience components, partial-
experience components, new components)
Development Environment (hardware and software required to be accessible by software team during
the development process)
Each resource is specified with four characteristics:
Description of the resource
Statement of availability
Time when the resource will be required Time Window
Duration of time that resource will be applied

Peop
le

Reusable Software
components

Hardware/software tools

Fig: Project Resources



Software Project Estimation Options

Delay estimation until late in the project.
Base estimates on similar projects already completed.
Use simple decomposition techniques to estimate project cost and effort.
Use empirical models for software cost and effort estimation.
Automated tools may assist with project decomposition and estimation.
Note: The accuracy of a software project estimate is predicted based on the product size; human effort,
calendar time, cost; software team; product requirement and environment.

Decomposition Techniques
It is "divide and conquer approach" to software project estimation.
Cost and effort estimation can be performed in a stepwise fashion by decomposing a project into major
functions and activities.
It should generates an estimates of Software sizing (fuzzy logic, function point, standard component,
change)
This techniques use either decomposition of the problem or the process.
o Problem-based estimation (using LOC decomposition focuses on software functions, using FP
decomposition focuses on information domain characteristics)
o Process-based estimation (decomposition based on tasks required to complete the software
process framework)

Further Reading

Software Sizing refers to a quantifiable outcome of the software project. Size can be measured in LOC, for
direct approach or FP, for indirect measure.
Four different approach to the sizing problem are:

1. "Fuzzy logic" sizing:
Approximate reasoning techniques to identify the type of application, establishing its magnitude on a
qualitative scale, and refine the magnitude within the original range.

2. Function point sizing:
Estimation of the information domain characteristics


3. Standard component sizing:
Estimation of the number of occurrence of each standard components ( subsystems, modules, screens,
reports, interactive programs, batch programs, files, LOC, object-level instructions) and use of
historical project data.

4. Change sizing:
Use of existing software for modification

Summary
The software project planner must estimate three things before a project begins: how long it will take, how
much effort will be required, and how many people will be involved. In addition, the planner must predict the
resources (hardware and software) that will be required and the risk involved.

Each step in the software engineering process should produce a deliverable that can be reviewed and that can
act as a foundation for the steps that follow. The software project plan is produced at the culmination of the
planning tasks. It provides baseline costs and scheduling information that will be used throughout the
software process.

The software project plan is a relatively brief document that is addressed to a diverse audience. It must (1)
communicate scope and resources to software management, (2) define risks and suggest risk aversion
techniques; (3) define cost and schedule for management review; (4) provide an overall approach to software
development for all people associated with the project; and (5) outline how quality will be ensured and
change will be managed.

It is important to note that the Software Project Plan is not a static document. That is, the project team revisits
the plan repeatedly- updating risks, estimates, schedules and related information- as the project proceeds.

The estimation of scope helps the planner to develop estimates using one or more techniques that fall into two
broad categories: decomposition and empirical model. Decomposition techniques requires a delineation of a
major software functions, followed by estimation of either ( 1) the number of LOC (2) selected values within
the information domain (3) the number of person-months required to implement each function, or (4) the
number of person-month required for each software engineering activity. Empirical techniques use
empirically derived expressions for effort and time to predict these project quantities. Automated tools can be

used to implement a specific empirical model. Software project estimation can never be an exact science, but a
combination of good historical data and systematic techniques can improve estimation accuracy.

Good project management is essential for project success
The intangible nature of software causes problems for management Managers have diverse roles but
their most significant activities are planning, estimating and scheduling
Planning and estimating are iterative processes which continue throughout the course of a project
A project milestone is a predictable state where some formal report of progress is presented to
management.

Project Scheduling - Overview

This chapter describes the process of building and monitoring schedules for software development projects.
To build complex software systems, many engineering tasks need to occur in parallel with one another to
complete the project on time. The output from one task often determines when another may begin. It is
difficult to ensure that a team is working on the most appropriate tasks without building a detailed schedule
and sticking to it.

Things done before project scheduling...

Selection of an appropriate process model
Identification of the software engineering tasks
Estimation of Work size, people
Calculation of deadline
Risk analysis
Things to do during scheduling....

Creation of activity network (Effort and duration allocated to each task and a task network)
Assign responsibility for each task

Project Scheduling
Software project scheduling is an activity that distributes estimated effort across the planned project
duration by allocating the effort to specific software engineering tasks.
Split project into tasks and estimate time and resources required to complete each task
Organize tasks concurrently to make optimal use of workforce
Minimize task dependencies to avoid delays caused by one task waiting for another to complete

Software Project Scheduling Principles

Compartmentalization - the product and process must be decomposed into a manageable number of
activities and tasks
Interdependency - tasks that can be completed in parallel must be separated from those that must
completed serially
Time allocation - every task has start and completion dates that take the task interdependencies into
account
Effort validation - project manager must ensure that on any given day there are enough staff
members assigned to completed the tasks within the time estimated in the project plan
Defined Responsibilities - every scheduled task needs to be assigned to a specific team member
Defined outcomes - every task in the schedule needs to have a defined outcome (usually a work
product or deliverable)
Defined milestones - a milestone is accomplished when one or more work products from an
engineering task have passed quality review
Project Scheduling Process

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts
Software Activity charts

requirements and bar charts
Scheduling Problem

Estimating the difficulty of problems and hence the cost of developing a solution is hard
Productivity is not proportional to the number of people working on a task
Adding people to a late project makes it later because of communication overheads
The unexpected always happens. Always allow contingency in planning

Relationship between People and Effort
Adding people to a project after it is behind schedule often causes the schedule to slip further
The relationship between the number of people on a project and overall productivity is not linear (e.g.
3 people do not produce 3 times the work of 1 person, if the people have to work in cooperation with
one another)

The main reasons for using more than 1 person on a project are to get the job done more rapidly and
to improve software quality.

Project Effort Distribution
40-20-40 rule recommends that 40 % of all effort is allocated to front-end analysis and design, and a similar
percentage is applied to back-end testing while remaining 20 % is allocated for coding part only.

Generally accepted guidelines are:

02-03 % planning
10-25 % requirements analysis
20-25 % design
15-20 % coding
30-40 % testing and debugging

Defining task set for the software projects
The software process model is populated by a set of tasks that enable a software team to define, develop and
ultimately support computer software.

A task sets is a collection of software engineering work tasks, milestones, and deliverables that must be
accomplished to complete a particular projects.

Task sets are designed to accommodate different types of projects and different degrees of rigor.

Software Project Types

Concept development - initiated to explore new business concept or new application of technology
New application development - new product requested by customer
Application enhancement - major modifications to function, performance, or interfaces (observable
to user)
Application maintenance - correcting, adapting, or extending existing software (not immediately
obvious to user)
Reengineering - rebuilding all (or part) of a legacy system


Software Process Degree of Rigor
It is a function of many software project characteristics. Four different degrees of rigor can be defined as:
Casual - all framework activities applied, only minimum task set required (umbrella activities
minimized and documentation reduced)
Structured - all framework and umbrella activities applied (SQA, SCM, documentation, and
measurement tasks are streamlined)
Strict - full process and umbrella activities applied (high quality products and robust documentation
produced)
Quick reaction - emergency situation, process framework used, but only tasks essential to good
quality are applied (back filling used to develop documentation and conduct additional reviews after
product is delivered)

Rigor Adaptation Criteria
Size of project
Number of potential users
Mission criticality
Application longevity
Requirement stability
Ease of customer/developer communication
Maturity of applicable technology
Performance constraints
Embedded/non-embedded characteristics
Project staffing
Reengineering factors

Task Set Selector Value
Computed by scoring rigor adaptation criteria and adjusting the scores using differential weighting
based on project characteristics.
Once computed the task selector value can be used to select the appropriate task set (casual,
structured, strict) for the project.
It is OK to choose a less formal degree of rigor when the task selector value falls in the overlap area
between two levels of rigor, unless project risk is high.


Concept Development Tasks
Concept scoping - determine overall project scope
Preliminary concept planning - establishes development team's ability to undertake the proposed
work
Technology risk assessment - evaluates the risk associated with the technology implied by the
software scope
Proof of concept - demonstrates the feasibility of the technology in the software context
Concept implementation - concept represented in a form that can be used to sell it to the customer
Customer reaction to concept - solicits feedback on new technology from customer

Project Planning Engineering Release Customer

Definition Evaluation
Concept Development
1.4 Proof of concept 1.6 Customer reaction

1.1Concept of scoping
1.2 Preliminary concept planning 1.5 Concept Implementation

1.3 Technology risk assessment
New Application
development
Application
enhancement
Application
maintenance
Reengineering

Fig: Concept development tasks in a linear sequential model

Note: Concept development projects are initiated when the potential for some new technology must be explored.

Task Network or Activity Network
A task network, also called an activity network, is a graphical representation of the task flow for a project. It is a
useful mechanism for depicting inter-task dependencies and determining the critical path. Critical path task
must be completed on schedule if the as a whole is to be completed on schedule.


1.1Concept
1.3a Tech. 1.5a Concept
scoping
risk Implement
assessment
1.2 1.3bTech. risk 1.4 Proof of 1.5bConcept Integrate

Concept assessment concept Implement a,b,c
Planning
1.3c Tech. 1.5c Concept

risk Implement 1.6
assessment Customer
Three 1.5 tasks are reaction
applied in parallel to 3
different concept
function

Project Scheduling Methods
Scheduling tools should be used to schedule any non-trivial project. PERT (program evaluation and review
technique) and CPM (critical path method) are quantitative techniques that allow software planners to identify
the chain of dependent tasks in the project work breakdown structure (WBS) that determine the project
duration time.

Timeline (Gantt) charts or Bar Chat is an alternative way of representing project schedule information that
enable software planners to determine what tasks will be need to be conducted at a given point in time (based
on estimates for effort, start time, and duration for each task). Bar charts show schedule against calendar time.
The best indicator of progress is the completion and successful review of a defined software work product.

Note: Activity Network and Bar Chart is the graphical notations used to illustrate the project schedule. It show
project breakdown into tasks. Tasks should not be too small. They should take about a week or two.

Time-boxing is the practice of deciding a priori the fixed amount of time that can be spent on each task. When
the task's time limit is exceeded, development moves on to the next task (with the hope that a majority of the
critical work was completed before time ran out).


Further Reading...
Milestones and Deliverables
Milestones are the end-point of a process activity. At each milestone, there should be a formal output (
such as report). It should represent the end of a distinct, logical stage in the project.
Deliverables are project results delivered to customer. It is usually delivered at the end of some major
project phase such as specification, design etc.
Deliverables are usually milestones but milestones may not be deliverables. Milestones may be
internal project results that are used by the project manager to check project progress but which are
not delivered to the customer.
To establish milestones, the software process must be broken down into basic activities with
associated outputs. Fig below shows activities involved in requirements specification when
prototyping is used to help validate requirements. The principle outputs for each activity ( the project
milestones) are shown. The project deliverables are the requirements definition and the requirements
specification.
ACTIVITIES

Feasibility Requirements Prototype Design Requirements
study analysis development study specification

Feasibility Requirements Evaluation Architectural Requirements
report definition report design specification

MILESTONES
Task duration and dependencies

Task Duration (days) Dependencies
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2,T4 (M2)
T6 5 T1,T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3,T6 (M4)
T10 15 T5,T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)

The above table shows activities, their duration, and activity interdependencies. It is seen that T3
(implementation of design) is dependent on Task T1 (task-preparation of a component design) , means T1
must be completed before T3 starts.

Given dependency and estimated duration of activities, an activity network, which shows activity
sequences, may be generated. It shows which activities can be carried out in parallel and which must be
executed in sequence because of a dependency on an earlier activity. Activities are represented as rectangles.
Milestones and deliverables are shown with rounded corners. Dates in the diagram shows the start date of the
activity and all activities must end in milestones.

Before progress can be made from one milestone to another, all paths leading to it must be complete.
For example, task T9 cannot be started until tasks T3 and T6 are finished. The arrival at milestone M4 shows
that these tasks have been completed.
The minimum time required to finish the project can be estimated by considering the longest path in
the activity graph (the critical path). Here, it is 11 weeks or elapsed time or 55 working days. In the activity
network, the critical path is shown as a sequence of emboldened boxes. The overall schedule of the project
depends on the critical path. Any slippage in the completion of any critical activity causes project delays.

Activity Network

14/7/99 15 days
15 days
M1 T3
8 days
T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99
M3
start 20 days 7 days
15 days
T7 T11
T2

25/7/99 11/8/99 5/9/99
10 days 10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days

T8 Finish
19/9/99

Activity Timeline or Gantt chart or Bar Chart


4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Start
T4
T1
T2
M1

T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
T12
Finish

Some of the activities in the above figure are followed by a shaded bar whose length is computed by the
scheduling tool. This shows that there is some flexibility in the completion date of these activities. If an activity
does not complete on time, the critical path will not be affected until the end of the period marked by the
shaded bar. Activities, which lie on the critical path, have no margin of error and they can be identified
because they have no associated shaded bar.

Staff Allocation

While scheduling the project, after the completion of the activity network, the allocation of staff to project
activities must be performed. Allocation of people to activities is shown in the table below.

Task Engineer
T1 Jane
T2 Anne
T3 Jane
T4 Fred
T5 Mary
T6 Anne
T7 Jim

T8 Fred
T9 Jane
T10 Anne
T11 Fred
T12 Fred

Staff allocation vs. time chart

4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10
Jim T7
Mary T5

Earned Value Analysis

Earned value is a quantitative measure of percent of project completed so far.
The total hours to complete the entire project are estimated and each task is given an earned value
based on its estimated percentage contribution to the total.

Error Tracking

Allows comparison of current work to past projects and provides a quantitative indication of the
quality of the work being conducted.
The more quantitative the approach to project tracking and control, the more likely problems can be
anticipated and dealt with in a proactive manner.

Summary

Scheduling is a culmination of a planning activity that is a primary component of software project
management. When combined with estimation methods and risk analysis, scheduling establishes a road map
for the project manager.
Scheduling begins with process decomposition. The characteristics of the project are used to adopt an
appropriate task set for the work to be done. A task network depicts each engineering task, its dependency on
other tasks, and its projected duration. The task network is used to compute the critical path, a timeline chart
(Gantt Chart) and a variety of project information. Using the schedule as a guide, the project manager can
track and control each step in the software process.

A project milestone is a predictable outcome of an activity where formal report of progress should be
presented to management. Milestones should occur regularly throughout a software project. A deliverable is a
milestone, which is delivered to the project customer.
Project Scheduling involves the creation of various graphical representations of part of the project plan. These
include activity charts showing the interrelationships of project activities and bar charts showing activity
durations.

Assessment Questions on Project Planning
Q1. Write a statement of scope that describes the software for a home security system. Be sure your statement
of scope is bounded.
Q2. Performance is an important consideration during planning. Discuss how performance can be interpreted
differently depending upon the software application area.
Q3. What do you mean by project planning and project scheduling? Explain the different activities which are
performed during project planning.
Q4. Explain why the intangibility of software system poses special problems for software project
management?
Q5. Explain why the process of project planning is an iterative one and why a plan must be continually
reviewed during a software projects?
Q6. Briefly explain the purpose of each of the sections in a software plan.
Q7. Develop a list of software characteristics that affect the complexity of projects. Prioritize the list.
Q8. It seems odd that cost and schedule estimates are developed during software project planning- before
detailed software requirements analysis or design has been conducted. Why do you think this is done? Are
there circumstances when it should not be done?

Assessment Questions on Project Scheduling
Q9. What is the difference between a macroscopic schedule and a detailed schedule? Is it possible to manage a
project if only a macroscopic schedule is developed? Why?
Q10. What is the critical distinction between a milestone and a deliverable?
Q11. Figure sets out a number of activities, durations and dependencies. Draw an activity chart and a bar chart
showing the project schedule.
Task Duration (days) Dependencies
T1 10
T2 15 T1
T3 10 T1,T2
T4 20
T5 10
T6 15 T3,T4
T7 20 T3
T8 35 T7
T9 15 T6
T10 5 T5,T9
T11 10 T9
T12 20 T10
T13 35 T3,T4
T14 10 T8,T9
T15 20 T12,T14
T16 10 T15

Q12. Highlight on the Critical Path for the above activity chart.

9. Formal Methods

Refer Slide: MCA_SE_Chapter_9_Formal_Methods.ppt


10. Specialized System Development
Real Time Systems
Real-time computing (RTC), or reactive computing, is the study of hardware and software systems that are
subject to a "real-time constraint"i.e., operational deadlines from event to system response. Real-time
programs must execute within strict constraints on response time. By contrast, a non-real-time system is one
for which there is no deadline, even if fast response or high performance is desired or preferred. The needs of
real-time software are often addressed in the context of real-time operating systems, and synchronous
programming languages, which provide frameworks on which to build real-time application software.
A real-time system may be one where its application can be considered (within context) to be mission critical.
The anti-lock brakes on a car are a simple example of a real-time computing system the real-time constraint
in this system is the time in which the brakes must be released to prevent the wheel from locking. Real-time
computations can be said to have failed if they are not completed before their deadline, where their deadline is
relative to an event. A real-time deadline must be met, regardless of system load.

Client Server System
Clientserver model of computing is a distributed application structure that partitions tasks or workloads
between the providers of a resource or service, called servers, and service requesters, called clients. Often
clients and servers communicate over a computer network on separate hardware, but both client and server
may reside in the same system. A server machine is a host that is running one or more server programs which
share their resources with clients. A client does not share any of its resources, but requests a server's content
or service function. Clients therefore initiate communication sessions with servers which await incoming
requests.

The clientserver characteristic describes the relationship of cooperating programs in an application. The
server component provides a function or service to one or many clients, which initiate requests for such
services.
Functions such as email exchange, web access and database access, are built on the clientserver model. Users
accessing banking services from their computer use a web browser client to send a request to a web server at
a bank. That program may in turn forward the request to its own database client program that sends a request
to a database server at another bank computer to retrieve the account information. The balance is returned to
the bank database client, which in turn serves it back to the web browser client displaying the results to the
user. The clientserver model has become one of the central ideas of network computing. Many business

applications being written today use the clientserver model. So do the Internet's main application protocols,
such as HTTP, SMTP, Telnet, and DNS.
The interaction between client and server is often described using sequence diagrams. Sequence
diagrams are standardized in the Unified Modeling Language.

Specific types of clients include web browsers, email clients, and online chat clients.

Specific types of servers include web servers, ftp servers, application servers, database servers, name
servers, mail servers, file servers, print servers, and terminal servers. Most web services are also types of
servers.

Distributed System
Distributed computing is a field of computer science that studies distributed systems. A distributed
system consists of multiple autonomous computers that communicate through a computer network. The
computers interact with each other in order to achieve a common goal. A computer program that runs in a
distributed system is called a distributed program, and distributed programming is the process of writing
such programs.
Distributed computing also refers to the use of distributed systems to solve computational problems. In
distributed computing, a problem is divided into many tasks, each of which is solved by one or more
computers.

Parallel System
Parallel computing is a form of computation in which many calculations are carried out simultaneously,
operating on the principle that large problems can often be divided into smaller ones, which are then
solved concurrently ("in parallel"). There are several different forms of parallel computing: bit-
level, instruction level, data, and task parallelism. Parallelism has been employed for many years, mainly
in high-performance computing, but interest in it has grown lately due to the physical constraints
preventing frequency scaling. As power consumption (and consequently heat generation) by computers has
become a concern in recent years, parallel computing has become the dominant paradigm in computer
architecture, mainly in the form of multicore processors.
Parallel computers can be roughly classified according to the level at which the hardware supports
parallelismwith multi-core and multi-processor computers having multiple processing elements within a

single machine, while clusters, MPPs, and grids use multiple computers to work on the same task. Specialized
parallel computer architectures are sometimes used alongside traditional processors, for accelerating specific
tasks.
Parallel computer programs are more difficult to write than sequential ones, because concurrency introduces
several new classes of potential software bugs, of which race conditions are the most
common. Communication and synchronization between the different subtasks are typically one of the greatest
obstacles to getting good parallel program performance.

Web Based System
Technically, the term Web-Based system refers to those applications or services that are resident on a server
that is accessible using a Web browser and is therefore accessible from anywhere in the world via the Web.

High Integrity system
SELF STUDY


Business Process Engineering- Overview
Information Engineering
When business automation was first introduced in the early 1960s, companies looked for areas of opportunity
and simply automated business functions that were previously performed in a manual fashion. As time
passed, individual computer programs were combined to encompass business applications. The applications
were grouped into major information systems that served specific business areas. Although this approach was
workable, it resulting in problems. Systems were difficult to connect to one another; redundant data was
everywhere; the impact of changes to applications that served one area of the business were difficult to
project and even more difficult to implement; old programs outlived their usefulness, but lack of resources
causes them to be used long past their prime.
In their book on "reengineering the corporation," Hammer and Champy [HAM93] state:
Information technology plays a crucial role in business reengineering, but one that is easily miscast. Modern,
state-of-the-art information technology is part of any reengineering effort, an essential enabler [that]
permits companies to reengineer business processes. But to paraphrase what is often said about money and
governments, merely throwing computers [and software] at an existing business problem does not cause it to
be reengineered.
The global objective of information engineering is to apply "information technology" in a way that best serves
the overall needs of the business. To accomplish this, IE must begin by analyzing business objectives and
goals, understanding the many business areas that must work together to achieve these objectives and goals,
and then define the information needs of each business area and the business as a whole. Only after this is
done, does IE make a transition into the more technical domain of software engineeringthe process where
information systems, applications, and programs are analyzed, designed and built.
Information Strategy Planning
The first information engineering step is information strategy planning (ISP). The overall objectives of ISP are:
(1) to define strategic business objectives and goals; (2) to isolate the critical success factors that will enable
the business to achieve these goals and objective; (3) to analysis the impact of technology and automation on
the goals and objectives, and (4) to analyze existing information to determine their role in achieving goals and
objective. ISP also creates a business-level data model that defines key data object and their relationship to one
another and to various business areas.

The terms objectives and goals take on a specific meaning in ISP. An objective is a general statement of
direction. For example, a business objective for a maker of cellular telephones might be: reduce the
manufactured cost of the product. Goals define a quantitative course of action. To achieve the objective noted
above, the manufacturer might state the following goals:
Decrease reject rate by 20 percent within 9 months

gain 10 percent price concessions from suppliers
reengineer keypad to reduce assembly cost by 30 percent
automate manual assembly of components
implement a real-time production control system
Objectives tend to be strategic. Goals are tactical.

Critical success factors (CSFs) can be tied to an objective or to individual goals. A CSF must be present if the
objective or goal is to be achieved. Therefore management planning must accommodate it. For example, CSFs
for the manufacturing objective noted above might be:
total quality management strategy for the manufacturing organization

worker training and motivation
higher reliability machines
higher quality parts
sales plan to convince supplier to reduce prices
availability of engineering staff
Technology impact analysis examines objectives and goals and provides an indication of those technologies
that will have a direct or indirect impact on achieving them successfully. The information engineer addresses
the following questions: How critical is the technology to the achievement of a business objective. Is the
technology available today. How will the technology change the way business is conducted. What are the
direct and indirect costs. How should the business adapt or extend objective and goals to accommodate the
technology
Because every business area makes some use of information technologies, ISP must also identify what
currently exists and how it is currently used to achieve objectives and goals. Business process reengineering
(BPR) is an activity that examines existing system with the intent of reengineering them to better meet
business needs.

Enterprise Modeling
Enterprise modeling creates a three dimensional view of a business. The first dimension addresses the
organizational structure and the functions that are performed within the business areas defined by the
organizational structure. The second dimension decomposes business function to isolate the processes that
make function happen. Finally, the third dimension relates objectives, goals, and CSFs to the organization and
its functions. In addition, enterprise modeling creates a business-level data model that defined data objects
and their relationships to other elements of the enterprise model.
The business organization is defined in a classical business unit hierarchy (e.g., an "org chart"). Each box in the
org chart represents a business area of the company. Like all hierarchies, it is generally possible to refined the
boxes within the org chart until small working groups or even individuals are noted. However, for ISP
purposes, business areas are all this required.
Business functions are identified and the processes that are required to implement the business functions are
defined. Each of the business functions is then related to the business area that has responsibility for it. In
general a business function is some on-going activity that must be accomplished to support the overall
business. A business process is a transform that accepts specific inputs and produces specific outputs.
To illustrate how a business function is refined into a set of supporting processes, consider the market
analysis function. A process refinement follows:
Market analysis:
Collect data on all sales inquiries
Collect data on all sales
Analyze data on inquires and sales
Develop buyer profile
Compare profile to demographic research
Study industry buying trends
Establish focus groups to determine best sales message
Design rough sales materials
Test sales materials and refine
Finalize sales approach
Each of the bulleted process steps could be further refined to provide a detailed road map for accomplishing
the business function.

During ISP, the information engineer does not become concerned with areas of automation opportunity. The
intent is simply to understand and model the business.
1.1.2 Business-Level Data Modeling
Business-level data modeling [SCH92] is an enterprise modeling activity that focuses on the data objects (also
called entities) that are required to achieve the business functions noted earlier. At the business level, typical
data objects include: producers and consumers of information (e.g., a customer), things (e.g., a report),
occurrences of events (e.g., a sales conference), organizational roles (e.g., a Vice President of Engineering);
organizational units (e.g., Sales and Marketing), places (e.g., manufacturing cell), or information structures
(e.g., an employee file). A data object contains a set of attributes that define some aspect, quality, characteristic
or descriptor of the data that is being described. For example, during enterprise modeling an information
engineer might define the data object: customer. To more fully describe customer, the following attributes
are defined:
Object: Customer
Attributes:
name
company name
job classification and purchase authority
business address and contact information
product interest(s)
past purchase(s)
date of last contact
status of contact
Once a set of data objects is defined, their relationships are identified. A relationship indicates how objects are
connected to one another. As an example, consider the objects: customer, product A, and salesperson. An
information engineer creates a entity relationship diagram ( E-R diagram) to depict these relationships.
Relationships imply a connection between data objects. In general, relationship can be read in either direction;
hence, a customer purchases product A and product A is purchased by a customer. In reality additional
information is provided as part of the data model
The culmination of the ISP activity is the creation of a series of cross reference matrices that establish the
overall relationships between the organization (and its business areas), business objectives and goals,
business functions, and data objects.

1.2 Business Area Analysis
In his book on information engineering, Martin [MAR90] describes business area analysis in the following
manner:
Business areas analysis (BAA) establishes a detailed framework for building an information-based enterprise.
It takes one business area at a time and analyzes it in detail. It uses diagrams and matrices to model and
record the data and activities in the enterprise and to give a clear understanding of the elaborate and subtle
ways in which the information aspects of the enterprise interrelate.
During BAA, our focus shifts from the world view to the domain view. To model "the elaborate and subtle
ways in which the information aspects of the enterprise interrelate," the information engineer must depict
how data objects (described during ISP and refined during BAA) are used and transformed within each
business area and how the business functions and processes within each business area transform these data
objects. In essence, both exogenous and endogenous data are analyzed and modeled for each business area.
To accomplish this work, BAA makes use of a number of different models:
data models (now refined to the business area level)

process flow models
process decomposition diagrams
a variety of cross-reference matrices
The data objects defined during ISP are refined for use within each business area. For example, the data object
customer described in the preceding section is used by the sales department. After evaluation of the needs of
the sales department (an analysis of the sales domain), the original definition of customer is further refined
to meet the needs of sales:
Object: Customer
Attributes:
name
company name Object: Company
job classification and purchase authority
business address and contact information
product interest(s)
past purchase(s)
date of last contact record of contacts

status of contact status of last contact
next contact date
recommended nature of contact
The attribute company name has been modified to point to another object called Company. This object
contains not only the company name but additional information about the size of the company, its purchasing
requirements, the name of other contacts, etc. This information will be useful in the sales domain. Other
attributes have been modified and added as noted above.
Process Modeling
The work performed within a business area encompasses a set of business functions that are further refined
into business processes. To illustrate, consider a simplified version of the sales function discussed earlier. The
processes that occur to accomplish sales are:
Sales function:
Establish customer contact

Provide product literature and related information
Address questions and concerns
Provide evaluation product
Accept sales order
Check availability of configuration ordered
Prepare delivery order
Confirm configuration, pricing, ship date with customer
Transmit delivery order to order fulfillment
Follow-up with customer
A process flow diagram can be developed for this sequence of processing. It should be noted that each
business function relevant to the business area can be refined in a similar manner.
Information Flow Modeling
The process flow model is integrated with the data model to provide an indication of how information flows
through a business area. Input and output data objects are shown for each process, providing an indication of
how the process transforms information to accomplish a business function.
Once a complete set of process flow models have been created, the information engineer (along with others)
examines how the existing process can be reengineered (e.g., [HAM93], [JAY94]) and where existing

information systems or applications might be modified or replaced by more efficient information
technologies. The revised process model is used as a basis for the specification of new or revised software to
support the business function. The domain view established during BAA serves as the basis for business system
design (BSD) and construction and integration (C&I)IE steps that are actually part of the software engineering
process.

The
enterprise Information strategy
planning
Business (World view)
Area

A business Business area
area
Analysis
(Domain view)

Processing

requirement

Information

system

Business system design Software Engineer
(Element view)

Construction &
Integration
(Detailed view)


Software Quality Assurance- Overview
This chapter provides an introduction for software quality assurance (SQA). SQA is the concern of every
software engineer to reduce cost and improve product time-to-market. A Software Quality Assurance Plan is
not merely another name for a test plan, though test plans are included in an SQA plan. SQA activities are
performed on every software project. Use of metrics is an important part of developing a strategy to improve
the quality of both software processes and work products.

Quality Concepts
v Quality as a characteristics or attribute of something.
v Quality, simplistically, means that a product should meet its specification
v Quality of design
o It refers to characteristics of an end item as specified by designer.
o In software development, it encompasses requirements, specifications, and the design of the
system.
v Quality of conformance
o Degree to which the design specifications are followed during manufacturing.
o In software, Quality of conformance focuses on the implementation part.
User satisfaction= compliant product+ good quality+ delivery within budget
and schedule.

Software quality defined...
Conformance to explicitly stated functional and performance requirements, explicitly documented development
standards, and implicit characteristics that are expected of all professionally developed software.

The above definition serves three important points:
l Software requirement forms a foundation for quality being measured. Lack of conformance to
requirements is lack of quality.
l If specified standards, that define a set of development criteria, is not followed; lack of quality will
almost surely result.
l If software conforms to its explicit requirements but fails to meet implicit requirements (ease of use
and maintainability), software quality is suspect.

Software quality management
v Concerned with ensuring that the required level of quality is achieved in a software product
v Involves defining appropriate quality standards and procedures and ensuring that these are followed

v Should aim to develop a quality culture where quality is seen as everyones responsibility

Quality Management activities
v Quality assurance
o Establish a framework of organizational procedures and standards for high-quality software.
o Consists of the auditing and reporting procedures used to provide management with data
needed to make proactive decisions.
o If data provided through QA identifies problems, management is responsible to address the
problems and apply the necessary resources to resolve quality issues.

v Quality planning
o Selection of appropriate procedures and standards from this framework and adaptation of
these for specific software projects and modify these as required.
o A quality plan sets out the desired product qualities and how these are assessed and define the
most significant quality attributes
o It should define the quality assessment process.
o It should set out which organisational standards should be applied and, if necessary, define
new standards.

v Quality control
o Definition and enactment of processes which ensure that the project quality procedures and
standards are followed by the software development team.
o Variation control is the heart of quality control (software engineers strive to control the
process applied, resources expended, and end product quality attributes).
o QC involves the series of inspection, reviews, and test used throughout the software process to
ensure conformance of a work product to its specifications.
o Feedback loop to the process that created the work product, minimize the defects produced.
o Key concept of QC- all work products have been defined, measurable specifications to compare
the output of each process.
o Two approaches to quality control
Quality reviews
Automated software assessment and software measurement

Quality management provides an independent check on the software development process. The deliverables
from the software process are input to the quality management process and are checked to ensure that they
are consistent with organizational standards and goals. As the quality assurance and control team should be
independent, they can rake an objective view of the process and can report problems and difficulties to senior
management in the organization.

Quality management should be separate from project management to ensure independence without
compromising on quality for project budget and schedule.
Software development D1 D2 D3 D4 D5
process

Quality management
process

Standards and Quality Quality review reports
procedures plan
Fig: Quality management and software development

Cost of Quality
It includes all costs incurred in the pursuit of quality or in performing quality related activities. Aim is to
provide a baseline for the current cost of quality, identify opportunities for reducing the cost of quality, and
provide a normalized basis of comparison.
Quality costs may be divided into costs associated with prevention, appraisal, and failure as mentioned below:
v Prevention costs - quality planning, formal technical reviews (FTR), test equipment, training.
v Appraisal costs includes activities to gain insight into product condition the "first time through" each
process. Example include - in-process and inter-process inspection, equipment calibration and
maintenance, testing.
v Failure costs
o Internal failure costs are incurred when a defect in a product is detected prior to shipment and
include - rework, repair, failure mode analysis
o External failure costs are associated with defects found after the product has been shipped to
the customer which include- complaint resolution, product return and replacement, help line
support, warranty work


Total Quality Management (TQM)
v Kaizen - develop a process that is visible, repeatable, and measurable.
v Atarimae hinshitsu - examine the intangibles that affect the process and work to optimize their
impact on the process.
v Kansei - examine the way the product is used by the customer with an eye to improving both the
product and the development process
v Miryokuteki hinshitsu - observe product use in the market place to uncover new product
applications and identify new products to develop.

Software Quality Assurance (SQA)
v The aim of SQA is to help an organization develop high quality software in a repeatable manner. A
repeatable development software organization is the one where the software development process is
person-independent.
v Conformance to software requirements is the foundation from which software quality is measured.
v Specified standards are used to define the development criteria that are used to guide the manner in
which software is engineered.
v Software must conform to implicit requirements (ease of use, maintainability, reliability, etc.) as well
as its explicit requirements.

SQA Group Activities
v Prepare SQA plan for the project.
v Participate in the development of the project's software process description.
v Review software engineering activities to verify compliance with the defined software process.
v Audit designated software work products to verify compliance with those defined as part of the
software process.
v Ensure that any deviations in software or work products are documented and handled according to a
documented procedure.
v Record any evidence of noncompliance and reports them to management.

Software Reviews
v Purpose is to find defects (errors) before they are passed on to another software engineering activity
or released to the customer.
v Software engineers (and others) conduct formal technical reviews (FTR) for software engineers.
v Using formal technical reviews (walkthroughs or inspections) is an effective means for improving
software quality.

Formal Technical Reviews
v Involves 3 to 5 people (including reviewers)
v Advance preparation (no more than 2 hours per person) required
v Duration of review meeting should be less than 2 hours
v Focus of review is on a discrete work product
v Review leader organizes the review meeting at the producer's request
v Reviewers ask questions that enable the producer to discover his or her own error (the product is
under review not the producer)
v Producer of the work product walks the reviewers through the product
v Recorder writes down any significant issues raised during the review
v Reviewers decide to accept or reject the work product and whether to require additional reviews of
product or not

Statistical Quality Assurance
v Information about software defects is collected and categorized
v Each defect is traced back to its cause
v Using the Pareto principle (80% of the defects can be traced to 20% of the causes) isolate the "vital
few" defect causes
v Move to correct the problems that caused the defects

Software Reliability
v Defined as the probability of failure free operation of a computer program in a specified environment
for a specified time period
v Can be measured directly and estimated using historical and developmental data (unlike many other
software quality factors)
v Software reliability problems can usually be traced back to errors in design or implementation.

Software Safety
v Defined as a software quality assurance activity that focuses on identifying potential hazards that may
cause a software system to fail.
v Early identification of software hazards allows developers to specify design features to can eliminate
or at least control the impact of potential hazards.
v Software reliability involves determining the likelihood that a failure will occur, while software safety
examines the ways in which failures may result in conditions that can lead to a mishap.


Mistake-Proofing Software
v Poka-yoke devices are mechanisms that lead to the prevention of a potential quality problem before it
occurs or to the rapid detection of a quality problem if one is introduced
v Poka-yoke devices are simple, cheap, part of the engineering process, and are located near the process
task where the mistakes occur

ISO Quality Standards
v International set of standards for quality management
v Applicable to a range of organisations from manufacturing to service industries
v Quality assurance systems are defined as the organizational structure, responsibilities, procedures,
processes, and resources for implementing quality management.
v ISO 9000 describes the quality elements that must be present for a quality assurance system to be
compliant with the standard, but it does not describe how an organization should implement these
elements.
v ISO 9001 is the quality standard that contains 20 requirements that must be present in an effective
software quality assurance system.
v ISO 9001 applicable to organisations which design, develop and maintain products
v ISO 9001 is a generic model of the quality process Must be instantiated for each organisation

ISO 9001

Management responsibility Quality system

Control of non-conforming products Design control
Handling, storage, packaging and Purchasing
delivery
Purchaser-supplied products Product identification and traceability
Process control Inspection and testing

Inspection and test equipment Inspection and test status

Contract review Corrective action
Document control Quality records
Internal quality audits Training
Servicing Statistical techniques
ISO 9000 Certification
v Quality standards and procedures should be documented in an organisational quality manual
v External body may certify that an organisations quality manual conforms to ISO 9000 standards
v Customers are, increasingly, demanding that suppliers are ISO 9000 certified

ISO 9000
quality models

instantiated as

documents
Organization Organization
quality manual quality process

is used to develop instantiated as

Project 1 Project 2 Project 3 Project quality
quality plan quality plan quality plan management

Supports

SQA Plan
v Management section - describes the place of SQA in the structure of the organization
v Documentation section - describes each work product produced as part of the software process
v Standards, practices, and conventions section - lists all applicable standards/practices applied during
the software process and any metrics to be collected as part of the software engineering work
v Reviews and audits section - provides an overview of the approach used in the reviews and audits to
be conducted during the project
v Test section - references the test plan and procedure document and defines test record keeping
requirements
v Problem reporting and corrective action section - defines procedures for reporting, tracking, and
resolving errors or defects, identifies organizational responsibilities for these activities
v Other - tools, SQA methods, change control, record keeping, training, and risk management

Assignments
1) Discuss the difference between black-box and structural testing and suggest how they can be used
together in the defect testing process.

2) Show, using a small example, why it is practically impossible to exhaustively test a program.

3) Explain why interface testing is necessary given that individual units have been extensively validated
through unit testing and program inspections.

4) Explain why bottom-up and top-down testing may be inappropriate testing strategies for object-oriented
systems.

5) What is black-box testing? Explain the advantages and disadvantages of back-box testing.

6) Why White-box testing is called Glass-box testing? Explain the flow graph-notation.


Software Engineering - Assignment Questions
Chapter-1: Introduction to software engineering
1) Briefly explain the various areas of software applications usually encountered. What is the difference
between software program and software product.

2) What do you understand by the common process framework of software development? List the
various umbrella activities that are being complemented by generic view of software engineering.

Chapter-2: Software Design
3) Differentiate between structured analysis and structured design in the context of function-oriented
design. Enumerate the shortcomings of DFDs as a tool for performing structured analysis.

4) What do you mean by the term data dictionary in the context of structured analysis? How is data
dictionary useful in different phases of the life cycle of a software product?

5) With the help of suitable example, explain how the inheritance feature of the object-oriented paradigm
helps in code reuse and design reuse. What is the difference between object-oriented analysis (OOA)
and object-oriented design (OOD)? Enumerate some of the important characteristics of a good object-
oriented design of systems.

6) What are the main advantages of using an object-oriented design approach over a function-oriented
approach? Point out the differences between these two approaches.

Chapter-4: Software tools and environments
7) Explain the terms CASE tool and CASE environment. Explain how CASE environment is different to
that of programming environment. Also list the main advantages of using CASE tools.

8) Discuss the role of data dictionary in a CASE environment.

9) Draw a schematic diagram of the architecture of a CASE environment and explain how the different
tools are integrated. Also explain how CASE tools can support various aspect of configuration
management?


10) Software engineering methods only become widely used when CASE technology become available to
support them. Suggest five types of method support which can be provided by CASE tools.

Chapter-5: Software processes
11) What do you understand by the term life cycle model of software development? Why is it important to
adhere to a life cycle model while developing a large software product?

12) Explain why the spiral model is considered to be a meta model. Compare the relative advantages of
using the waterfall model and the spiral model of software development.

13) Which life cycle model would you follow for developing software products for each of the following
applications? Enumerate the reasons for your choice of a particular life cycle model.
i. A well understood EDP applications
ii. A new software product that would connect computers through satellite communication.
Assume that your team has no previous experience in developing satellite communication
software.
iii. A software product that would function as the controller of a telephone switching system.
iv. A new library automation software that would link various libraries in the city.
v. An extremely large software that would provide, monitor, and control cellular communication
among its subscribers using a set of revolving satellites.
vi. A new text editor.
vii. A compiler for a new language

Chapter-6: Software requirements and specification
14) What do you mean by Software requirement engineering? Explain in brief the common process
framework associated with requirement engineering.

15) Why is it so difficult to gain a clear understanding of what the customer wants? What might be the
appropriate solution to overcome such difficulty? Explain and justify your reasons.

16) What do you understand by formal methods of software specification? What are the desired
properties of formal specification? Discuss the relative advantages of formal requirements
specification over informal requirements specification. What are the various formal specification
languages you have come across while preparing Formal specification documents?

17) Compare and contrast functional requirements with non-functional requirements with an appropriate
example.
18) State the various specification principles that should be realized while preparing software
requirement specification? What candidate format would you recommend for the development of the
SRS document?
19) What are the various requirements validation techniques you have come across while preparing the
software requirements specification? Explain with a relevant example.
20) What is a prototype model? Under what circumstances it is beneficial to construct a prototype model.
List the various advantages of first developing the prototyping of a system.

Chapter-7: Software Validation
21) Why are three different levels of testing-unit testing, integration testing and system testing-necessary?
What is the main purpose of each of these different levels of testing? How can project scheduling affect
integration testing?
22) Compare and contrast black-box testing with white-box testing? Explain in brief the various
techniques used in both the test case design strategy?
23) Explain why bottom-up and top-down testing may be inappropriate testing strategies for object-
oriented systems.
24) What is black-box testing? Explain the advantages and disadvantages of back-box testing.
25) Why White-box testing is called Glass-box testing?
26) Distinguish between software verification and software validation. Do both make use of test case
design methods and testing strategies?
27) What do you understand by the term system testing? What are the different kinds of system testing
that are usually performed on large software products?
28) What is regression testing? Why is regression testing necessary?
29) Explain the four levels of testing in an object-oriented system.
Chapter 8: Software evolution
30) Explain why a software system which is used in a real world environment must change or become
progressively less useful?
31) What are the different types of maintenance that a software product might need? Discuss the process
models available for software maintenance and indicate how you would select an appropriate model
for a maintenance project on hand?
32) What do you mean by the term software reverse engineering? What are the key advantages of re-
engineering? Also explain how re-engineering is different from forward engineering.


33) Briefly explain the re-engineering process with an aid of suitable block diagram.

34) Explain the various stages of software re-engineering process model.

35) What do you mean by the term software reverse engineering? Explain the reverse engineering process
with a diagram.

36) What do you mean by the term legacy system? What difficulties are likely to arise when different
components of a legacy system are implemented in different programming languages? Why most
legacy systems use a function-oriented approach to design than an object-oriented design strategy?

Chapter 9: Software Project Management
37) List the various activities that are associated with the software project planning and scheduling?

38) What do you mean by software estimation. Explain the various types of software estimation
techniques. In what way software estimation techniques help in pricing the medium size software
product?

39) What do you mean by Function-oriented metric? Explain. What are the relative advantages of using
either the LOC or the function point metric to measure the size of a software product?

40) Explain COCOMO estimation model. What are the different categories of software according to the
COCOMO estimation model? Give examples of software products belonging to each of these categories.

41) Suppose you are developing a software product in the organic mode. You have estimated the size of
the product to be about 100,000 lines of code. Compute the nominal effort and the development time.

42) Suppose that a software product for a business application costs Rs 50,000 off-the-shelf and that its
size is 40 KLOC. Assuming that in-house engineers cost Rs 6000 per programmer-month (including
overheads), would it be cost effective to buy the product or build it?

43) Describe principles of software project scheduling. Briefly explain the software project scheduling
process.


44) Deliverables are usually milestones but milestones may not be deliverables. Justify this statement
with an appropriate example.

45) The following table indicates the various tasks involved in completing a software project, the
corresponding activities, and the estimated effort for each task in programmer-months
Notation Activity Effort in PM
T1 Requirements specification 1
T2 Design 2
T3 Code actuator interface module 2
T4 Code sensor interface module 5
T5 Code user interface part 3
T6 Code control processing part 1
T7 Integrate and test 6
T8 Implementation 3

46) The precedence relation Ti <={Tj,Tk} implies that the task Ti must be completed before either task Tj or
task Tk can start. The following precedence relation is known to hold among different tasks:
T1<=T2<={T3,T4,T5,T6} <=T7. Draw an activity network diagram.

47) Figure sets out a number of activities, durations and dependencies. Draw an activity network diagram
and also highlight on the Critical Path for this activity diagram.

Task Duration Dependencies
(days)
T1 10
T2 15 T1
T3 10 T1,T2
T4 20
T5 10
T6 15 T3,T4
T7 20 T3
T8 35 T7
T9 15 T6
T10 5 T5,T9
T11 10 T9

T12 20 T10
T13 35 T3,T4
T14 10 T8,T9
T15 20 T12,T14
T16 10 T15

48) What according to you is a quality software product? Briefly explain the various quality factors or
attributes associated with a software product. Show the relationship between internal and external
software attributes.
49) Define Software quality assurance (SQA). Explain the various types of standard that may be
established as part of the quality assurance process. Identify a list of fundamental tasks that must be
included in an SQA plan.
50) What is meant by software configuration management (SCM)? Why is SCM crucial to the success of
large software product development projects? How is software configuration managed? (List the
names of principle activities involved.) What is the relationship between software configuration
management and software maintenance?

Chapter 11: Specialized system development
51) Explain why an object-oriented approach to software development may not be suitable for real time
systems and usually implemented using concurrent processes.

52) What do you mean by the term client/server systems? What are the various software components for
client/server systems? Explain.

53) Prepare a quality requirement tree that leads to high quality Web applications. Is there any
difference between Web engineering and software engineering. Justify with an example of web-based
application with reference to any organic software product.

54) Write short notes on:
i. SEI-Capability Maturity Model level 5
ii. Facilitated Action Specification Techniques (FAST)
iii. Lehmans law
iv. Petrinets as formal methods of specification.
v. Application Program Interface (API)

Software Engineering

Uploaded by

Copyright:

Available Formats

Software Engineering

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering

Uploaded by

Copyright:

Available Formats

Software Engineering MCA II

SOFTWARE ENGINEERING: A DEFINITION

Software engineering is:

The software engineer job encompasses a fairly wide range of responsibilities.

Common Job Responsibilities for Software Engineer

1. Full lifecycle application development

Common IT Hardware, Software, Platform and Systems Knowledge

Requirements for Software Engineers:

Software Engineering Code of Ethics and Professional Practice

7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

1.01. Accept full responsibility for their own work.

Principle 2: CLIENT AND EMPLOYER

Software engineers shall maintain integrity and independence in their professional

4.06. Refuse to participate, as members or advisors, in a private, governmental or professional body

5.07. Offer fair and just remuneration.

6.01. Help develop an organizational environment favorable to acting ethically.

6.02. Promote public knowledge of software engineering.

6.03. Extend software engineering knowledge by appropriate participation in professional organizations,

7.01. Encourage colleagues to adhere to this Code.

7.02. Assist colleagues in professional development.

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.

2. Design Concepts and Principles

A software design is a meaningful engineering representation of some software product that is to be

An API can be:

CodeWarrior for Microsoft Windows, Mac OS, and embedded systems

Microsoft Visual Studio

Apple Xcode for Mac OS X

Programming by example (PbE),

Programming by example (PbE), also known as programming by demonstration or more generally

Component-based software engineering (CBSE)

Component-based software engineering (CBSE) (also known as component-based development (CBD)) is a

Requirement analysis and design modeling tools

Configuration Management Tools

Tools Integration Mechanism

(2) The study of approach as in (1).

Common process framework

Define outline Assign requirements Design system

Develop system Validate Integrate Validate

Increment 4 Analysis Design Code Test

Product Organizational External

Efficiency Reliability Portability Interoperability Ethical

Usability Delivery Implementation Standards Legislative

Performance Space Privacy Safety

Software Requirements Analysis Phases

Methods based analysis

Create a cognitive model rather than an implementation model.

3. Test case generation

Requirements validation checklist

Test Plan Test Code Validate Run Test

Level 2 Level 2 Level 2 Level 2

Locate Design Repair Re-test

sarojpandey.com.np 100 of 146

sarojpandey.com.np 101 of 146

sarojpandey.com.np 103 of 146

sarojpandey.com.np 104 of 146

sarojpandey.com.np 105 of 146

sarojpandey.com.np 107 of 146

sarojpandey.com.np 108 of 146

sarojpandey.com.np 109 of 146