Software Engineering

Questions and answers

2010-09-07T22:23:00.001-07:00

1. What is meant by Risk?
The problem that could cause some loss or threaten the success of the
project, but which has not happened yet. The potential problems might have an adverse impact on cost, schedule, or technical success of the project, the quality of our software products, or project morale. Risk management is the process of identifying addressing and eliminating these problems before they can damage the project.

2. Brief HIPO diagram
HIPO diagram were developed at IBM as design representation schemes
Top down software development and as external documentation aids for released products. HIPO diagram contains a
 visual table of contents
 a set of overview diagrams, and
 a set of detail diagrams.
o The visual table of contents is a directory to the set of diagrams in the package. It consists of tree-structured directory, a summary of the contents of each overview diagram, and a legend

3. Brief s/w maintenance

S/W maintenance is the very broad activity that includes error corrections, enhancements of capabilities, deletion of obsolete capabilities, and optimization. Change is inevitable, mechanisms must be developed for evaluating, controlling and making modifications. So any work done to change the software after it is in operation is considered to be maintenance. The purpose is to preserve the value of the s/w overtime. The value can be enhanced by expanding the customer base, meeting additional requirements, becoming easier to use, more efficient and employing newer technology. Maintenance may span for 50 years, whereas development may be 1-2 years.

4. What are all the solutions to Maintenance Problems

A number of possible solutions to maintenance problems have been suggested. They include: budget & effort reallocation; complete replacement of existing systems; and enhancement of existing systems.

Budget & effort Reallocation

It is now-a-days suggested that more time and resources should be invested in the development-specification & design of more maintainable systems rather than allocating resources to develop unmentionable or difficult to maintain systems

Complete replacement of the system
If maintaining an existing system costs as much as developing a new one, why not develop a new system from scratch. This point of view is understandable, but in practice it is not simple. The risk and costs associated with complete system replacement are very high. Corrective & preventive maintenance take place periodically at relatively small but incremental costs. Some organization can afford to pay for these comparatively small maintenance charges while at the same time supporting more ambitious and financially demanding project may not be possible.

Maintenance of Existing System

Complete replacement of the system is not usually a viable option. An operational system in itself can be asset to an organization in terms of the investment in technical knowledge and the working culture engendered. The current system may need to have the potential to evolve to a higher state.

5. Software Reengineering

Software reengineering is concerned with taking existing legacy systems and re implementing them to make them more maintainable. As a part of this reengineering process, the system may be redocumented or restructured. It may be translated to a more modern programming language, implemented on existing hardware technology. Software re-engineering allows us to translate source code to a new language, restructure our old code, migrate to a new platform capture and then graphically display design information, and redocument documented systems.

New S/W Development Re-engineering

The costs of re-engineering depend on the extent of the work that is carried out. Other factors affecting costs are the quality of the software. The following suggestions may be useful for the modification of the legacy code:

• Study code well before attempting changes
• Concentrate on overall control flow not coding
• Heavily comment internal code
• Create Cross references
• Build Symbol tables
• Use own variables, constants and declaration to localize the effect of change
• Keep detailed maintenance document
• Use modern design techniques

6. Define Modularity

Modularity is the way of defining the system as a collection of well defined, manageable units with well defined interfaces among the units. Desirable properties of a modular system include:

• Each module is a well defined subsystem that is potentially useful in other applications
• Each module has a single, well defined purpose.
• Modules can be separately compiled and stored in a library
• Modules can use other modules.
• Modules should be easier to use than to build
• Modules should be simpler from the outside than from the inside.

Modularity is the single attribute from the outside than from the inside be intellectually manageable. It enhances the design clarity , which in turn eases implementations, debugging, documenting and maintenance of the s/w product.

7. What do you mean by Abstraction?

Abstraction is the intellectual tool that allows us to deal with concepts apart from particular instances of those concepts. During requirements definition an design, abstraction permits separation of the conceptual aspects of a system from the implementation details. We can specify the FIFO property of a queue or the LIFO property of a stack without concern for the representation scheme to be used in implementing the stack or queue.
Three widely used abstraction mechanism in s/w design are
 functional abstraction
 data abstraction
 control abstraction.

Functional Abstraction

It involves the use of parameterized subprograms. The ability to parameterize a subprogram and to bind different parameter values on different invocations of the subprogram is a powerful abstraction mechanism.

Data Abstraction

It involves specifying a data type or a data object by specifying legal operations on objects. Represention and manipulation details are suppressed. Abstract data type is used to denote decleration of data type from which numerous instances can be created. Abstract data types are abstract in the sense that representation details of the data items and implementation details of the functions that manipulate the data items are hidden within the group that implements the abstract type.

Control Abstraction

It is the third commonly used abstraction mechanism in software design. Control abstraction is used to state a desired effect without stating the exact mechanism of control. IF statements and WHILE statements in modern programming languages are abstractions of machine code implementations that involve conditional jump instructions. A statement of the form

“for all I in S sort files I”
leaves unspecified the sorting techniques, the nature of S, the nature of the files, and how “for all I in S” is to be handled.

8. What is the Modularization Criteria?

A s/w module to be a named entity has the following characteristics:
1. Modules contain instruction, processing logic, and data structures
2. Modules can be separately compiled and stored in a library
3. Modules can be included in a program
4. Module segments can be used by invoking a name and some parameters.
5. Modules can use other modules.

Modularization allows the designer to decompose a system into functional units to impose hierarchical ordering on functional usage, to implement data abstractions, and to develop independently useful subsystems.

9. Define Coupling and Cohesion

Coupling is the measure of the degree of interdependence between modules. Two modules with high coupling are strongly interconnected and thus, dependent on each other. Two modules with low coupling are not dependent on one another. The strength of coupling between two modules is influenced by the complexity of the interface, the type of connection, and the type of communication . Modification of a common data block or control block may require modification of all routines that coupled to that block. If modules communicate only parameters, and if the interfaces between modules remain fixed, the internal details of modules can be modified without having to modify the routines that use the modified modules. Coupling between modules can be ranked on a scale of strongest to weakest as follows:
1. Content coupling
2. Common coupling
3. Control coupling
4. Stamp coupling
5. Data coupling

10. Define Cohesion?

Cohesion is the measure of the degree to which the elements of a module are functionally related. A strongly cohesive module implements functionality that is related to one feature of the solution and requires little interaction with other modules. The internal cohesion of a module is measured in terms of the strength of binding of elements within the module. Cohesion of elements occurs on the scale of weakest to strongest as follows:
1. Coincidental cohesion
2. Logical Cohesion
3. Temporal cohesion
4. Communication cohesion
5. sequential cohesion
6. Functional Cohesion
7. Informational cohesion

11. What is meant by specification principles?

A number of specification principles adapted from the work of Balzer and Goldman is as follows:
1. Separate functionality from implementation
2. Develop a model of the described behaviour of a system that encompases the data and the functional responses of a system to various stimuli from the environment
3. Establish the context in which software operates by specifying the manner in which other system components interact with software.
4. Define the environment in which the system operates and indicates how “a highly intertwined collection of agents react to stimuli in the environment produced by those agents.
5. Create a cognitive model rather than a design or implementation model. The cognitive model describes a system as perceived by its user community.

12. Give the importance of Risk analysis

Risk always involves two characteristics:
Uncertainity- The event that characterizes the risk may or may not happen; i.e. there are no 100% probable risk
Loss: If the risk becomes a reality, unwanted consequences or losses will occur.

It is important to quantify the level of uncertainty and the degree of loss associated with the each risk. Different categories of risks are considered. Different categories of risks are considered.
Project risk : If project risk become real, it is likely that the project schedule will slip and that cost will increase.
Technical risks: It threaten the quality and timeliness of the s/w to be produced. If a technical risk becomes a reality, implementation may become difficult or impossible.
Business risks: It threatens the viability of the s/w to be built.
Known risks: The risks are uncovered after careful evaluation of the project plan, the business and technical environment in which the project is being developed.

13. Define s/w Reliability
S/W reliability is defined in statistical term as “The probability of failure free operation of a computer program in a specified environment for a specified time”
Eg. Program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. i.e. if a program X were to be executed 100 times and require eight hours of elapsed processing time, it is likely to operate correctly 96 times out of 100.
According to s/w quality and realiability failure is nonconformance to s/w requirements. For a computer based system a simple measure of reliability is mean time between failure (MTBF) where
MTBF = MTTF + MTTR
MTTF - mean time to failure
MTTR – mean time to repair

14. Explain the various classifications of s/w metrics

Project Metrics
Size oriented metrics
S/W metrics are derived by normalizing quality and/or productivity measures by considering the “size “ of the s/w that has been produced . If a s/w organization maintains simple records, a table of size-oriented measures.
Function oriented metrics

S/w metrics use a measure of the functionality delivered by the application as a normalization value. Functionality can not be measured directly, it must be derived indirectly using other direct measures. Measurement is done by function point. Function points are derived using an empirical relationship based on countable measures of software’s information domain and assessments of software complexity.

Extended Function Point metrics

The function point metric was originally designed to be applied to business information systems applications. To accommodate these applications, the data dimension was emphasized to the exclusion of the functional and behavioral dimensions.

15. Brief COCOMO model

The name COCOMO stands for COnstrutive COst MOdel. It is an hierarchy model.
Basic COCOMO Model: It computes software development effort as function of program size expressed in estimated lines of code

Italic COCOMO Model: It computes software development effort as a function of program size and a set of cost drivers that include subject assessments of product, hardware, personnel, and project attributes.

Advanced COCOMO Model: It incorporates all characteristics of the intermediate version with an assessment of the cost driver’s impact on each step of the s/w engineering process.

16. Give the various s/w testing strategies
White box testing
It is also called as glass box testing. It is a test case design method that uses the control structure of the procedural design to derive test cases.

Basis path testing method
The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure for defining a basis set of execution paths.

Control structure Testing

(i) Condition Testing
A simple condition is a Boolean variable or a relational expression, possibly preceded with one NOT operator
(ii) Data Flow testing
Data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.
(iii) Loop testing
Black box testing
Black box testing focuses on the functional requirements of the s/w. Black box testing enables the s/w engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.

17. What is the need for baseline?
Change is a fact of life in s/w development Customers want to modify requirements. Developers want to modify technical approach. Managers want to modify project approach. A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change.
After an initial baseline is established and forzen, every subsequent change is recorded as delta until the next baseline is set. It is desirable to establish a baseline at an early point in every project. Establishing a baseline too early, will impose unnecessary procedures and slow the programmers’ work.
Baseline Scope
For code control, the baseline contains all the project code. The items to be included for the implementation phase are
o Current level of each module, including source and object code
o Current level of each test case, including source and object code
o The current level of any special test or operational data
o The current level of all macros, libraries, and files

18. Brief the need of SCM

Software configuration management is a set of activities that have been developed to manage change throughout the the life cycle of computer software. SCM can be viewed as a s/w quality assurance activity that is applied throughout the s/w process. The output of the s/w process is information that may be divided into three broad categories
(i) Computer programs
(ii) Documents that describes the program
(iii) Data

As the s/w process progresses , the number of software configuration items(SCIs) grows rapidly. A system specification spawns a s/w project plan and s/w requirements specification.

19. List out the s/w configuration items

The following SCIs become the target for configuration management techniques and form a set of baselines.
1. System specification
2. Software project plan
3. Software Requirements Specification
(a) Graphical analysis models
(b) Process specifications
(c) Prototype
(d) Mathematical specification
4. Preliminary User Manual
5. Design specification
a) Data Design Description
b) Architectural design specification
c) Module design description
d) Interface design descriptions
e) Object descriptions
6. Source code listing
7. Test spcification
a) Test plan and procedures
b) Test cases and recorded results
8. Operation and Installation Manuals
9. Executed Program
a) Module executable code
b) Linked Modules
10. Database Descriptions
a) Schema file structure
b) Initial content
11. As-built User manual
12. Maintenance Documents
a) Software problem reports
b) Maintenance requests
c) Engineering change orders
13. Standards and procedures for s/w engineering

20. Write about SCM standards

Over the past two decades a number of s/w configuration management standards have been proposed. Many early SCM standards, such as MIL-STD-483, DOS-STD-480A, and MIL-STD-1521A, focused on s/w developed for militry applications. More recent ANSI / IEEE standards such as ANSI / IEEE Std. No. 1042-1987, and Std.No. 1028-1988, are applicable for commercial software and recommended for both large and small software engineeringorganizations.

21. What is the role of SQA

The people responsible for the s/w projects are the only ones who can be responsible for quality. The role of SQA is to monitor the way these groups perform their responsibilities.

1. Review all development and quality plans for completeness
2. Participate as inspection moderators in design and code inspections
3. Review all test plans for adherence to standards
4. Review a significant sample of all test results to determine adherence toplans
5. Periodically audit SCM performance to determine adherence to standards
6. Participat in all project quarterly and phase reviews and register ononconcurrence if the appropriate standards and procedures have not been reasonably met.

22. Write about SQA plan

Each development and maintenance project should have Software Quality Assurance Plan (SAQP) that specifies its goals, the SQA tasks to be performed the standards against which the development work is to be measured, and the procedures and organizational structure.
The IEEE standard for SQAP preparation contains the following outline
 Purpose
 Reference Documents
 Management
 Documentation
 Standards, Practices, and Conventions
 Reviews and audits
 Software configuration Management
 Problem reporting and Corrective Action
 Tools, techniques, and methodologies
 Code controls
 Media control
 Supplier control
 Records collection, Maintenance, and Retention

The documentation section should describe the documentation to be produced and how it is to be reviewed.

23. Define testing, verification, validation and debugging

Testing
The process of executing a program with the intention of finding errors
Verification
An attempt to find erros by executing program in a test or simulated environment
Validation
An attempt to find erros by executing a program in a real environment

Debugging
Diagnosing the precise nature of a known error and then correcting it.

24. What are all the types of testing
1. Unit or Module test
It verifies single programs or modules. These are typically conducted in isolated or special test environments

2. Integration tests
It verifies the interfaces between system parts (modules, components, and subsystems)
3. External function tests
It verifies the external system functions, as stated in the external specifications
4. Regression tests
It runs a subset of previously executed integration and function tests to ensure that program
5. System tests
It verifies and/or validate the system to its initial objectives
6. Acceptance tests
It validates the system or program to the user’s requirements
7. Installation test
It validate the installability and operability of the user’s system

25. What do you mean by Regression testing

Regression testing is particularly important in software maintenance,where it is not uncommon for bug fixes to disrupt seemingly unrelated functions.
The basic regressing testing approach is to incorporate selected test cases into a regression test bucket that is run periodically in an attemp to detect
Regression problems.

26. What are all the element of s/w plan

1. Goals and objectives: It describes what is to be done, for whom, and by when, as well as the criteria for determining project success
2. Work Breakdown structure(WBS) The WBS subdivides the project into tasks that are each defined, estimated and tracked.
3. Product size estimates: These are quantitative assessments fo the code required for each product element. Contingencies are applied to yield reasonable estimates of the resources required fro each WBS element.
4. Project Shedule: Based on the available project staffing and resource estimates, a schedule for the key tasks and deliverable items is produced.

2010-09-07T02:21:00.001-07:00

Software Configuration Management

See more presentations by ahmedajaz | Upload your own PowerPoint presentations

Practical Programming

2010-09-07T02:13:00.000-07:00

Software Development Life Cycle [SDLC]

2010-09-07T02:10:00.001-07:00

Agile Software Development

2010-09-07T02:10:00.000-07:00

Lecture - 26 Agile Development

2010-09-07T02:09:00.001-07:00

Lecture - 22 Verification and Validation

2010-09-07T02:09:00.000-07:00

Software Testing Interview Questions Tutorial

2010-09-07T02:06:00.000-07:00

Lecture 1 | Programming Methodology (Stanford)

2010-09-07T02:05:00.001-07:00

Lecture - 1 Introduction to Software Engineering

2010-09-07T02:05:00.000-07:00

Lecture - 2 Introduction to Software Engineering

2010-09-07T02:04:00.000-07:00

2010-09-02T03:58:00.000-07:00

UNIT II-PLANNING AND MANAGING THE PROJECT

Planning and Managing the Project

Tracking Progress

• Do we understand customer’s needs?

• Can we design a system to solve customer’s problems or satisfy customer’s needs?

• How long will it take to develop the system?

• How much will it cost to develop the system?

Project Schedule

• Describes the software-development cycle for a particular project by

– enumerating the phases or stages of the project

– breaking each phase into discrete tasks or activities to be completed

• Portrays the interactions among the activities and estimates the times that each task or activity will take

Project Schedule: Approach

• Understanding customer’s needs by listing all project deliverables

– Documents

– Demonstrations of function

– Demonstrations of subsystems

– Demonstrations of accuracy

– Demonstrations of reliability, performance or security

• Determining milestones and activities to produce the deliverables

Milestones and activities

• Activity: takes place over a period of time

• Milestone: completion of an activity -- a particular point in time

• Precursor: event or set of events that must occur in order for an activity to start

• Duration: length of time needed to complete an activity

• Due date: date by which an activity must be completed

Project Personnel

• Key activities requiring personnel

– requirements analysis

– system design

– program design

– program implementation

– testing

– training

– maintenance

– quality assurance

• There is great advantage in assigning different responsibilities to different people

Choosing Personnel

• Ability to perform work

• Interest in work

• Experience with

– similar applications

– similar tools, languages, or techniques

– similar development environments

• Training

• Ability to communicate with others

• Ability to share responsibility

Management skills

• A project's progress is affected by

– degree of communication

– ability of individuals to communicate their ideas

• Software failures can result from breakdown in communication and understanding

Project Organization

• Depends on

– backgrounds and work styles of team members

– number of people on team

– management styles of customers and developers

• Examples:

– Chief programmer team: one person totally responsible for a system's design and development

– Egoless approach: hold everyone equally responsible

Effort Estimation

• Estimating project costs is one of the crucial aspects of project planning and management

• Estimating cost has to be done as early as possible during the project life cycle

• Type of costs

– facilities: hardware, space, furniture, telephone, etc

– software tools for designing software

– staff (effort): the biggest component of cost

Type of Estimation Methods

• Expert judgment

• Top-down or bottom-up

• Analogy: pessimistic (x), optimistic (y), most likely (z); estimate as (x + 4y + z)/6

• Delphi technique: based on the average of “secret” expert judgments

• Algorithmic methods: E = (a + bS^c) m(X)

• Walston and Felix model: E = 5.25 S ^0.91

• Bailey and Basili model: E = 5.5 + 0.73 S^1.16

COCOMO model

• Introduced by Boehm

• COCOMO II

– updated version

– include models of reuse

• The basic models

– E = bS^cm(X)

– where

• bS^c is the initial size-based estimate

• m(X) is the vector of cost driver information

Risk Management

• Risk is an unwanted event that has negative consequences

• Distinguish risks from other project events

– Risk impact: the loss associated with the event

– Risk probability: the likelihood that the event will occur

• Quantify the effect of risks

– Risk exposure = (risk probability) x (risk impact)

• Risk sources: generic and project-specific

• Three strategies for risk reduction

• Avoiding the risk: change requirements for performance or functionality

• Transferring the risk: transfer to other system, or buy insurance

• Assuming the risk: accept and control it

• Cost of reducing risk

• Risk leverage = (risk exposure before reduction – (risk exposure after reduction) / (cost of risk reduction)

Boehm’s Top Ten Risk Items

• Personnel shortfalls

• Unrealistic schedules and budgets

• Developing the wrong functions

• Developing the wrong user interfaces

• Gold-plating

• Continuing stream of requirements changes

• Shortfalls in externally-performed tasks

• Shortfalls in externally-furnished components

• Real-time performance shortfalls

• Straining computer science capabilities

Project Plan
Project Plan Contents

• Project scope

• Project schedule

• Project team organization

• Technical description of system

• Project standards and procedures

• Quality assurance plan

• Configuration management plan

• Documentation plan

• Data management plan

• Resource management plan

• Test plan

• Training plan

• Security plan

• Risk management plan

• Maintenance plan

Project Plan Lists

• List of the people in development team

• List of hardware and software

• Standards and methods, such as

– algorithms

– tools

– review or inspection techniques

– design language or representaions

– coding languages testing techniques

Process Models and Project Management

• Establish an appropriately large shared vision

• Delegate completely and elicit specific commitments from participants

• Inspect vigorously and provide supportive feedback

• Acknowledge every advance and learn as the program progresses

Information System Example
Piccadilly System

• Using COCOMO II

• Three screens and one report

– Booking screen: complexity simple, weight 1

– Ratecard screen: complexity simple, weigth 1

– Availability screen: complexity medium, weight 2

– Sales report: complexity medium, weight 5

• Estimated effort = 182 person-month

Ariane-5 System

• The Ariane-5 destruction might have been prevented had the project managers developed a risk management plan

– Risk identification: possible problem with reuse of the Ariane-4)

– Risk exposure: prioritization would have identified if the inertial reference system (SRI) did not work as planned

– Risk control: assesment of the risk using reuse software

– Risk avoidance: using SRI with two different designs

The Requirements Process

• A requirement is an expression of desired behavior

• A requirement deals with

– objects or entities

– the state they can be in

– functions that are performed to change states or object characteristics

• Requirements focus on the customer needs, not on the solution or implementation

– designate what behavior, without saying how that behavior will be realized

Why Are Requirements Important

• Top factors that caused project to fail

– Incomplete requirements

– Lack of user involvement

– Unrealistic expectations

– Lack of executive support

– Changing requirements and specifications

– Lack of planning

– System no longer needed

• Some part of the requirements process is involved in almost all of these causes

• Requirements error can be expensive if not detected early

• Performed by the req. analyst or system analyst

• The final outcome is a Software Requirements Specification (SRS) document

Agile Requirements Modeling

• If requirements are tighly coupled and complex, we may be better off with a “heavy” process that empasizes up-front modeling

• If the requirements are uncertain, agile methods are an alternative approach

• Agile methods gather and implement the requirements in increments

• Extreme Programming (XP) is an agile process

– The requirements are defined as we build the system

– No planning or designing for possible future requirements

– Encodes the requirements as test cases that eventually implementation must pass

Requirements Elicitation

• Customers do not always undertand what their needs and problems are

• It is important to discuss the requirements with everyone who has a stake in the system

• Come up with agreement on what the requirements are

– If we can not agree on what the requirements are, then the project is doomed to fail

Requirements Elicitation Stakeholders

• Clients: pay for the software to be developed

• Customers: buy the software after it is developed

• Users: use the system

• Domain experts: familiar with the problem that the software must automate

• Market Researchers: conduct surveys to determine future trends and potential customers

• Lawyers or auditors: familiar with government, safety, or legal requirements

• Software engineers or other technology experts

Using Viewpoints to Manage Inconsistency

• No need to resolve inconsitencies early in the requirements process (Easterbrook and Nuseibah, 1996)

• Stakeholders' views documented and maintained as separate Viewpoints through the software development process

– The requirements analyst defines consistency rules that should apply between Viewpoints

– The Viewpoints are analyzed to see if they conform to the consistency requirements

• Inconsistencies are highlighted but not adressed until there is sufficient information to make informed decision

• Interviewing stake holders

• Reviewing available documentations

• Observing the current system (if one exists)

• Apprenticing with users to learn about user's task in more details

• Interviewing user or stakeholders in groups

• Using domain specific strategies, such as Joint Application Design, or PIECES

• Brainstorming with current and potential users

Types of Requirements

• Functional requirement: describes required behavior in terms of required activities

• Quality requirement or nonfunctional requirement: describes some quality characteristic that the software must posses

• Design constraint: a design decision such as choice of platform or interface components

• Process constraint: a restriction on the techniques or resources that can be used to build the system

Making Requirements Testable

• Fit criteria form objective standards for judging whether a proposed solution satisfies the requirements

– It is easy to set fit criteria for quantifyable requirements

– It is hard for subjective quality requirements

• Three ways to help make requirements testable

– Specify a quantitave description for each adverb and adjective

– Replace pronouns with specific names of entities

– Make sure that every noun is defined in exaclty one place in the requirements documents

Types of Requirements Resolving Conflicts

• Different stakeholder has different set of requirements

– potential conflicting ideas

• Need to prioritize requirements

• Prioritization might separate requirements into three categories

– essential: absolutely must be met

– desirable: highly desirable but not necessary

– optional: possible but could be eliminated

Two Kinds of Requirements Documents

• Requirements definition: a complete listing of everything the customer wants to achieve

– Describing the entities in the environment where the system will be installed

• Requirements specification: restates the requirements as a specification of how the proposed system shall behave

Characteristics of Requirements

• Correct

• Consistent

• Unambigious

• Complete

• Feasible

• Relevant

• Testable

• Traceable

Modeling Notations

• It is important to have standard notations for modeling, documenting, and communicating decisions

• Modeling helps us to understand requirements thoroughly

– Holes in the models reveal unknown or ambiguous behavior

– Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements

Entity-Relationship Diagrams

• A popular graphical notational paradigm for representing conceptual models

• Has three core constructs

ER Diagrams Example: UML Class Diagram

• UML (Unified Modeling Language) is a collection of notations used to document software specifications and designs

• It represents a system in terms of

– objects: akin to entities, organized in classes that have an inheritance hierarchy

– methods: actions on the object's variables

• The class diagram is the flagship model in any UML specification

– A sophisticated ER diagram relating the classes (entities) in the specification

Event Traces

• A graphical description of a sequence of events that are exchanged between real-world entities

– Vertical line: the timeline of distinct entity, whose name appear at the top of the line

– Horizontal line: an event or interaction between the two entities bounding the line

– Time progresses from top to bottom

• Each graph depicts a single trace, representing one of several possible behaviors

• Traces have a semantic that is relatively precise, simple and easy to understand

Functions and Relations Example: Decision Tables

Algebraic Specifications Example: SDL Data

Requirements and Specification Languages Unified Modeling Language (UML)

Requirements and Specification Languages Specification and Description Language (SDL)

Requirements and Specification Languages SDL System Diagram

Requirements and Specification Languages SDL Block Diagram

Prototyping Requirements Building a Prototype

Prototyping Requirements Prototyping vs. Modeling

• Prototyping

– Good for answering questions about the user interfaces

• Modeling

– Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities

Requirements Documentation Requirement Definition: Steps Documenting Process

Validation and Verification

• In requirements validation, we check that our requirements definition accurately reflects the customer's needs

• In verification, we check that one document or artifact conforms to another

• Verification ensures that we build the system right, whereas validation ensures that we build the right system

Measuring Requirements

Choosing a Specification Technique Criteria for Evaluating Specification Methods

Information System Example

Real-Time Example

UNIT III-DESIGNING THE SYSTEM

Designing the Architecture

The Design Process

• Design is the creative process of figuring out how to implement all of the customer’s requirements; the resulting plan is also called the design

• Early design decisions address the system’s architecture

• Later design decisions address how to implement the individual units

Design is a Creative Process

• Many ways to leverage existing solutions

Many tools for understanding options and evaluating chosen architecture, including

Design Process Model

Collaborative Design

Agile Architectures

• Helpful to use agile process when there is a great deal of uncertainly about requirements

• Agile architectures are based on four premises:

• Possible problems with agile methods:

Modeling Architectures

• Collection of models helps to answer whether the proposed architecture meets the specified requirements

• Six ways to use the architectural models:

Decomposition and Views

Popular Design Methods

• Some design problems have no existing solutions

– Designers must decompose to isolate key problems

• Some popular design methods:

– Functional decomposition

– Feature-oriented decomposition

– Data-oriented decomposition

– Process-oriented decomposition

– Event-oriented decomposition

– Object-oriented design

Popular Design Methods

• Functional decomposition

• Feature-oriented decomposition

• Data-oriented decomposition

Process-oriented decomposition

Decomposition and Views

• Component

• Subsystem

• Runtime process

• Module

• Class

• Package

• Library

• Procedure

• Software unit

• Modular

• Well-defined

• Component-based software engineering (CBSE) is a method of software development whereby systems are created by assembling together preexisting components

• A component is “a self-contained piece of software with a well-defined set of interfaces” that can be developed, bought, and sold as a distinct entity

• The goal of CBSE is to support the rapid development of new systems, by reducing development to component integration, and to ease the maintenance of such systems by reducing maintenance to component replacement

• At this point, CBSE is still more of a goal than a reality with considerable on-going research

Architectural Views

• Common types of architectural views include:

– Decomposition view

– Dependencies view

– Generalization view

– Execution view

– Implementation view

– Deployment view

– Work-assignment view

Dependencies View

• The dependencies view shows dependencies among software units

• This view is useful in project planning

• Also useful for assessing the impact of making a design change to some software unit

Generalization View

Execution View

Implementation View

Deployment View

Work-assignment View

Architectural Styles and Strategies

• Pipes-and-Filter

• Client-Server

• Peer-to-Peer

• Publish-Subscribe

• Repositories

• Layering

Achieving Quality Attributes

• Architectural styles provide general beneficial properties. To support specific quality attribute tactics are utilized:

– Modifiability

– Performance

– Security

– Reliability

– Robustness

– Usability

– Business goals

Collaborative Design

• Usually the design of software systems is performed by a team of developers

• Several issues must be addressed by the team:

– Who is best suited to design each aspect of the system

– How to document all aspects

– How to coordinate and integrate the software units

• Important to view group interaction in its cultural and ethical contexts

The Causes of Design Breakdown

Documenting Software Architectures

• Document rationale: outlining critical issues and trade-offs

When to document the rationale behind decision

Architecture Design Review

Software Product Lines

Designing the Modules

Design Methodology

Refactoring

• Design decisions are periodically revisited and revised

• Refactoring

• Objective: to simplify complicated solutions or to optimize the design

Design Principles

• Design principles are guidelines for decomposing a system’s required functionality and behavior into modules

• The principles identify the criteria

– for decomposing a system

– deciding what information to provide (and what to conceal) in the resulting modules

• Six dominant principles:

– Modularity

– Interfaces

– Information hiding

– Incremental development

– Abstraction ,Generality

Faking” a Rationale Design Process

OO Design

• A class is a software module that partially or totally implements an abstract data type

• If a class is missing implementations for some of its methods, we say that it is an abstract class

• The class definition includes constructor methods that spawn new object instances

• Instance variables are program variables whose values are references to objects

Inheritance vs. Object Composition

Substitutability

Law of Demeter

: Allows reducing dependencies by including in each composite class methods for operating on the class’s components

Dependency Inversion

Representing OO Designs in the UML

UML in the Process

• Use case diagrams

• UML activity diagrams

• Domain model

• Component diagrams

• Deployment diagrams

• Class diagrams

• Interaction diagrams

• Sequence diagrams

• Communication diagrams

• Activity diagrams

• State diagrams

• Package diagrams

OO Design Patterns

Other Design Considerations

OO Measurement

OO Size Measures

OO Design Quality Measures

Design Documentation

UNIT IV-TESTING THE PROGRAMS

Writing the Programs

Programming Standards and Procedures

• Standards for you

– methods of code documentation

• Standards for others

– Integrators, maintainers, testers

– Prologue documentation

– Automated tools to identify dependencies

• Matching design with implementation

– Low coupling, high cohesion, well-defined interfaces

Programming Standards at Microsoft

Programming Guidelines

Algorithms

Control Structures

Data Structures

Documentation

• Internal documentation

– header comment block

– meaningful variable names and statement labels

– other program comments

– format to enhance understanding

– document data (data dictionary)

• External documentation

– describe the problem

– describe the algorithm

– describe the data

Testing the Programs

Software Faults and Failures

• Wrong requirement: not what the customer wants

• Missing requirement

• Requirement impossible to implement

• Faulty design

• Faulty code

• Improperly implemented design

Objective of Testing

Types of Faults

Testing Issues

Testing Organization

Testing Object-Oriented Systems

Test Planning

• Establish test objectives

• Design test cases

• Write test cases

• Test test cases

• Execute tests

• Evaluate test results

Purpose of the Plan

• Test plan explains

– who does the testing

– why the tests are performed

– how tests are conducted

– when the tests are scheduled

Automated Testing Tools

• Dynamic analysis

– program monitors: watch and report program’s behavior

• Test execution

– Capture and replay

– Stubs and drivers

– Automated testing environments

• Test case generators

UNIT V-MAINTAINING THE SYSTEM

Testing the System

Principles of System Testing

Techniques Used in System Testing

Regression Testing

The Consequences of Not Doing Regression Testing

Configuration Management

Deltas and Separate Files

Test Team

Function Testing

Performance Tests

Purpose and Roles

Types of Performance Tests

• Stress tests

• Volume tests

• Configuration tests

• Compatibility tests

• Environmental tests

• Quality tests

• Recovery tests

• Maintenance tests

• Documentation tests

• Human factors (usability) tests

• Regression tests

• Security tests

• Timing tests

Reliability, Availability, and Maintainability Definition

Acceptance Tests

• Pilot test: install on experimental basis

• Alpha test: in-house test

• Beta test: customer pilot

• Parallel testing: new system operates in parallel with old system

Installation Testing

• Before the testing

– Configure the system

– Attach proper number and kind of devices

– Establish communication with other system

• The testing

– Regression tests: to verify that the system has been installed properly and works

Automated System Testing

Test Documentation

• Test plan: describes system and plan for exercising all functions and characteristics

• Test specification and evaluation: details each test and defines criteria for evaluating each feature

• Test description: test data and procedures for each test

• Test analysis report: results of each test

Testing Safety

Delivering the System

• It is more than just putting the system in place

• It is also helping users to understand and feel comfortable with the system

– Training

– Documentation

Training

Documentation