Documentos de Académico
Documentos de Profesional
Documentos de Cultura
1. What is software engineering? What are the attributes of good software? Key
challenges facing Software Engineering.] [Dec 2014, July 2013, Dec 2015, June
2015,June 2016] [5 to 10M]
1. Maintainability
The software should be written in a way that it can be evolve to meet changing needs of the
customer. Since the change of needs (requirement change of customer) is unavoidable, this is a
CRITICAL ATTRIBUTE.
2. Dependability
A software MUST be Trustworthy ( can we trust the software ? ) , Reliable , Safe and Secured (
are we secured using this software ? ) . Use of the software should not be harmful to the customer
in anyway (even something goes wrong) . Even at a system failure, dependable software should
NOT cause physical or economical damage. Also malicious users should not be able to access or
damage the system.
3. Efficiency
A software should be efficient in every way. The software should not make wasteful of system
resources (ex. memory, processing cycles) . Responsiveness should be there, and the memory
utilization should be minimum and also the processing time is a consideration.
4. Acceptability
The software must be acceptable to the group of users for which it's designed for Software should
be understandable, reliable and compatible with other systems they use
1. Heterogeneity
This says, developing techniques for building software, that can cope with heterogeneous
platforms ( changing platforms / different platforms ) and execution environments ( executing
environment ) .
2. Delivery
Delivery is another concern in software engineering . So developing techniques that can make the
delivery fast, described in ' DELIVERY ' .
3. Trust
A software must be trusted . Here ' TRUST ' means that developing techniques that demonstrate
that software can be trusted by its users .
4. Computer misuse: Software engineers should not use their technical skills to
misuse other peoples computers. Computer misuse ranges from relatively trivial
(game playing on an employers machine, say) to extremely serious
(dissemination of viruses).
1. System categories
a. Technical computer-based systems: Systems that include hardware and
software but where the operators and operational processes are not normally
considered to be part of the system. The system is not self-aware.
1. Properties of the system as a whole rather than properties that can be derived from
the properties of components of a system
A Consequence of The Relationships Between System Components
Only be assessed and measured once the components have been
integrated into a system
2. Volume
Total space occupied
3. Reliability
Depends on component reliability
Unexpected interactions cause new failure
4. Security
Ability to resist attack
5. Reparability
How easy to fix a problem
6. Usability
How easy to use the system
A Bicycle has the functional property of being a transportation device once it has been
assembled from its components.
Failure to achieve some minimal defined level in these properties may make the system
unusable.
4. Describe briefly the phases of System engineering process with neat diagram.
[June 2013, Dec 2014, June 2015] [10M] [5M]
System Design:
The activities involved in this process are:
I. Partition requirements You analyse the requirements and organise them into related
groups. There are usually several possible partitioning options, and you may suggest a
number of alternatives at this stage of the process.
2. Identify sub-systems You should identify sub-systems that can individually or
collectively meet the requirements. Groups of requirements are usually related
to sub-systems, so this activity and requirements partitioning may be amalgamated.
However, sub-system identification may also be influenced by other organizational or
environmental factors.
3. Assign requirements to sub-systems You assign the requirements to subsystems.
In principle, this should be straightforward if the requirements partitioning is used to
drive the sub-system identification. In practice, there is never a clean match between
requirements partitions and identified sub-systems.
Limitations of externally purchased sub-systems may mean that you have to change the
requirements to accommodate these constraints.
4. Specify sub-system functionality You should specify the specific functions provided
by each sub-system. This may be seen as part of the system design phase.
5. Define sub-system interfaces You define the interfaces that are provided and required
by each sub-system. Once these interfaces have been agreed upon, it becomes possible to
develop these sub-systems in parallel.
System modeling:
During the system requirements and design activity, systems may be modelled as a set of
components and relationships between these components. These are normally illustrated
graphically in a system architecture model that gives the reader an overview of the
system organisation.
The system architecture may be presented as a block diagram showing the major sub-
systems and the interconnections between these sub-systems. When drawing a block
diagram, you should represent each sub-system using a rectangle, and you should show
relationships between the sub-systems using arrows that link these rectangles.
The relationships indicated may include data flow, a uses'/' used by' relationship or some
other type of dependency relationship.
Sub-system development:
During sub-system development, Ihe sub-systems identified during system design are
implemented. This may involve starting another system engineering process for
individual sub-systems or, if the sub-system is software, a software process involving
requirements, design, implementation and testing.
Systems integration:
During the systems integration process, you take the independently developed
subsystems and put them together to make up a complete system. Integration can be done
using a 'big bang' approach, where all the sub-systems are integrated at the same time.
However, for technical and managerial purposes, an incremental integration process
where sub-systems are integrated one at a time is the best approach, for two reasons:
1. It is usually impossible to schedule the development of all the sub-systems so that they
are all finished at the same time.
2. Incremental integration reduces the cost of error location. If many sub-systems are
simultaneously integrated, an error that arises during testing may be in any of these sub-
systems. When a single sub-system is integrated with an already working system, errors
that occur are probably in the newly integrated sub-system or in the interactions between
the existing subsystems and the new sub-system.
System evolution:
Large, complex systems have a very long lifetime. During their life, they are changed to
correct errors in the original system requirements and to implement new requirements
that have emerged. The system's computers are likely to be replaced with new, faster
machines. System evolution is inherently costly for several reasons:
1. Proposed changes have to be analyzed very carefully from a business and a technical
perspective. Changes have to contribute to the goals of the system and should not simply
be technically motivated.
2. Because sub-systems are never completely independent, changes to one subsystem
may adversely affect the performance or behavior of other subsystems.
Consequent changes to these sub-systems may therefore be needed.
3. The reasons for original design decisions are often unrecorded. Those responsible for
the system evolution have to work out why particular design decisions were made.
4. As systems age, their structure typically becomes corrupted by change so the costs of
making further changes increases.
UNIT -2
The goal of this model is to provide a framework for designing such process,
guided by the risk levelsin the project at hand. The spiral model may be viewed as
a meta-model.
This model focuses on identifying and eliminating high risk problems by careful
process design.
3. What are the four basic process activities? Explain the general model of design
process with a neat diagram. . [June 2014] [10M]
Process activities:
1. Software specification The functionality of the software and constraints on its
operation must be defined.
2. Software design and implementation The software to meet the specification must be
produced.
3. Software validation The software must be validated to ensure that it does what the
customer wants.
4. Software evolution The software must evolve to meet changing customer needs.
3. Interface design For each sub-system, its interface with other sub-systems is designed
and documented. This interface specification must be unambiguous as it allows the sub-
system to be used without knowledge of the sub-system operation.
4. Component design Services are allocated to components and the interfaces of these
components are designed.
5. Data structure design The data structures used in the system implementation are
designed in detail and specil1ed.
6. Algorithm design The algorithms used to provide services are designed in detail and
specified.
These are:
1. Inception The goal of the inception phase is to establish a business case for the system.
2. Elaboration The goals of the elaboration phase are to develop an understanding of the
problem domain, establish an architectural framework for the system, develop the project
plan and identify key project risks.
3. Construction The construction phase is essentially concerned with system design,
programming and testing. Parts of the system are developed in parallel and integrated
during this phase.
4. Transition The final phase of the RUP is concerned with moving the system from the
development community to the user community and making it work in a real
environment.
For critical systems, it is usually the case that the most important system property
is the dependability of the system.
The dependability of a system reflects the users degree of trust in that system. It
reflects the extent of the users confidence that it will operate as users expect and
that it will not fail in normal use.
Usefulness and trustworthiness are not the same thing. A system does not have to
be trusted to be useful
Dimensions of dependability
UNIT-3
Example, here are examples of functional requirements for a university library system
called LIBSYS, used by students and faculty to order books and documents from other
libraries.
1. The user shall be able to search either all of the initial set of databases or select a
subset from it.
2. The system shall provide appropriate viewers for the user to read documents in the
document store.
2. Every order shall be allocated a unique identifier (ORDER_ID), which the user shall
be able to copy to the account's permanent storage area.
Non-functional requirements are not just concerned with the software system to be
developed. Some non-functional requirements may constrain the process that should be
used to develop the system. Examples of process requirements include a specification of
the quality standards that should be used in the process, a specification that the design
must be produced with a particular CASE toolset and a description of the process that
should be followed.
2. What are the metrics used to specify non-functional system properties? [July
2013] [5 M]
Sl No Property Measure
1 Speed Processed
transaction/second
Probability of
unavailability
Rate of failure
occurance
Availability
4. Explain requirements elicitation and analysis process and its activities. [ Jan 2014]
[10M]
Dept of CSE, SJBIT Page 14
Software Engineering 10IS51
The term stakeholder is used to refer to any person or group who will be affected by the
system, directly or indirectly. Stakeholders include end-users who interact with the
system and everyone else in an organisation that may be affected by its installation.
Other system stakeholders may be engineers who are developing or maintaining related
systems, business managers, domain experts and trade union representatives.
Eliciting and understanding stakeholder requirements is difficult for several reasons:
1. Stakeholders often don't know what they want from the computer system except in the
most general terms. They may find it difficult to articulate what they want the system to
do or make unrealistic demands because they are unaware of the cost of their requests.
2. Stakeholders naturally express requirements in their own terms and with implicit
knowledge of their own work. Requirements engineers, without experience in the
customer's domain, must understand these requirements.
3. Different stakeholders have different requirements, which they may express in
different ways. Requirements engineers have to consider all potential sources of
requirements and discover commonalities and conflict.
4. Political factors may influence the requirements of the system. For example, managers
may demand specific system requirements that will increase their influence in the
organisation.
5. The economic and business environment in which the analysis takes place is dynamic.
It inevitably changes during the analysis process. Hence the importance of particular
requirements may change. New requirements may emerge from new stakeholders who
were not originally consulted.
A very general process model of the elicitation and analysis process is shown in figure:
UNIT-4
1. What is data-flow model? With an example show the notations used in data
flow model. [ Dec 2015, June 2015] [10M]
Data-flow models are an intuitive way of showing how data is processed by a system.
At the analysis level, they should be used to model the way in which data is processed in
the existing system. Data-flow models are used to show how data flows through a
equence of processing steps. For example, a processing step could be to filter duplicate
records in a customer database. The data is transformed at each step before moving on to
the next stage. These processing steps or transformations represent software processes or
functions when data-flow diagrams are used to document a software design.
A data-flow model, which shows the steps involved in processing an order for goods
(such as computer equipment) in an organisation, is illustrated in figure.
This particular model describes the data processing in the Place equipment order activity
in the overall process model shown in fig. The model shows how the order for the goods
moves from process to process. It also shows the data stores (Orders file and Budget file)
that are involved in this process.
2. Explain the object aggregation with example. [Dec 2015 ,July 2014] [5M]
Object aggregation: an object is an aggregate of a set of other objects. The cla
representing these objects may be modeled using an object aggregation model, as shown
in figure.
Example: Model of a library item, which is a study pack for a university course.
This study pack includes lecture notes, exercises, sample solutions, copies of
transparencies used in lectures, and videotapes. The UML notation for aggregation is to
represent the composition by including a diamond shape on the source of the link.
Therefore figure can be read as 'A study pack is composed of one of more assignments,
OHP slide packages, lecture notes and videotapes.
A state machine model describes how a system responds to internal or external events.
The state machine model shows system states and events that cause transitions from one
state to another. It does not show the flow of data within the system. This type of model
is often used for modeling real-time systems because these systems are often driven by
stimuli from the system's environment.
System modeling : System modeling helps the analyst to understand the functionality
of the system and models are used to communicate with customers
Different models present the system from different perspectives
External perspective showing the systems context or environment
Behavioral perspective showing the behavior of the system
Structural perspective showing the system or data architecture
Context models
Context models are used to illustrate the boundaries of a system
Social and organizational concerns may affect the decision on where to position
system boundaries
Architectural models show the a system and its relationship with other systems
Behavioural models
Behavioural models are used to describe the overall behaviour of a system
Two types of behavioural model are shown here
Data processing models that show how data is processed as it moves through the system
State machine models that show the systems response to events
Both of these models are required for a description of the systems behaviour
Structured methods
Structured methods incorporate system modeling as an inherent part of the method
Methods define a set of models, a process for deriving these models and rules and
guidelines that should apply to the models
CASE tools support system modeling as part of a structured method
1. Explain why it is necessary to design the system architecture. What are the
system factors affected by system architecture. [June 2015] [10M]
2. With an example describe the repository model and give its advantages and
disadvantages. [ Jan 2014,June 2013] [5M]
A system model based on a shared database is called a repository model. Below figure is
an example of a CASE toolset architecture based on a shared repository.
Control models at the architectural level are concerned with the control flow between
sub-systems. There are two generic control styles that are used in software systems:
1. Centralised control One sub-system has overall responsibility for control and starts
and stops other sub-systems. It may also devolve control to another subsystem but will
expect to have this control responsibility returned to it.
Event-driven control models are driven by externally generated events. The tenn event in
this context does not just mean a binary signal. two event-driven control models:
1. Broadcast models: In these models, an event is broadcast to all sub-systems.
Any sub-system that has been programmed to handle that event can respond to it.
2. Interrupt-driven models: These are exclusively used in real-time systems where
external interrupts are detected by an interrupt handler. They are then passed to some
other component for processing.
A control model based on selective broadcasting:
4. Explain the object and object oriented design process. [ Dec 2015] [6M]
Stages:
1. Understand and define the context and the modes of use of the system.
2. Design the system architecture.
3. Identify the principal objects in the system.
4. Develop design models.
5. Specify object interfaces.
The system context and the model of system:
Use to represent two complementary models of the relationships between a system and its
environment:
1. The system context is a static model that describes the other systems in that
environment.
2. The model of the system use is a dynamic model that describes how the system
actually interacts with its environment.
Architectural design:
Example: The three layers in weather station software:
1. The interface layer that is concerned with all communications with other parts of the
system and with providing the external interfaces of the system;
2. The data collection layer that is concerned with managing the collection of data from
the instruments and with summarizing the weather data before transmission to the
mapping system;
3. The instruments layer that is an encapsulation of all of the instruments used to collect
raw data about the weather conditions.
Object identification:
There have been various proposals made about how to identify object classes:
1. Use a grammatical analysis of a natural language description of a system.
2. Use tangible entities (things) in the application domain such as aircraft, roles such as
manager, events such as request, interactions such as meetings,
3. Use a behavioral approach where the designer first understands the overall behavior of
the system.
4. Use a scenario-based analysis where various scenarios of system use are identified and
analysed in turn.
Design models:
Design models show the objects or object classes in a system and, where appropriate, the
relationships between these entities. Design models essentially are the design. They are
the bridge between the requirements for the system and the system implementation. This
means that there are conflicting requirements on these models.
There are two types of design models that should normally be produced to describe an
object-oriented design:
1. Static models describe the static structure of the system using object classes and their
relationships. Important relationships that may be documented at this stage are
generalisation relationships, uses/used-by relationships and composition relationships.
2. Dynamic models describe the dynamic structure of the system and show the
interactions between the system objects (not the object classes). Interactions that may be
documented include the sequence of service requests made by objects and the way in
which the state of the system is related to these object interactions.
Object interface specification: An important part of any design process is the
specification of the interfaces between the components in the design. You need to specify
interfaces so that objects and sub-systems can be designed in parallel. Once an interface
has been specified, the developers of other objects may assume that interface will be
implemented.
5. Write short notes on client server model, layered model. [June 2015] [10M]
Client-server model
Distributed system model which shows how data and
processing is distributed across a range of components
Wide-bandwidth network
Client-server characteristics
Advantages
Distribution of data is straightforward
Makes effective use of networked systems. May require
cheaper hardware
Easy to add new servers or upgrade existing servers
Disadvantages
No shared data model so sub-systems use different data
organization. Data interchange may be inefficient
Redundant management in each server
No central register of names and services - it may be hard to
find out what servers and services are available
UNIT 6
5. What are the different types of software maintenance? What are the key factors that
distinguish development and maintenance? [Dec 2014] [10M]
4. Program age and structure: As programs age, their structure tends to be degraded by
change, so they become harder to understand and modify. Some systems have been
developed without modem software engineering techniques. They may never have been
well structured and were perhaps optimized for efficiency rather than understandability.
6. With a neat diagram describe the system evolution process. [Dec 2014,June 2016] [7M]
The system evolution process
Change implementation
UNIT -7
1. What is verification and validation? Explain. [Dec 2015, June 2015] [5M]
Verification and validation (V &V) is the process of checking and analysis. Meaning of
Verification and validation:
'Validation: Are we building the right product?'
'Verification: Are we building the product right?'
Static and dynamic verification and validation:
Within the V & V process, there are two complementary approaches to system checking
and analysis:
1. Software inspections or peer reviews analyse and check system representations such as
the requirements document, design diagrams and the program source code. You can use
inspections at all stages of the process. Inspections may be supplemented by some
automatic analysis of the source text of a system or associated documents. Software
inspections and automated analyses are static V &
V techniques, as you don't need to run the software on a computer.
2. Software testing involves running an implementation of the software with test data.
You examine the outputs of the software and its operational behavior to check that it is
performing as required. Testing is a dynamic technique of verification and validation.
with interactions between errors. Consequently, a single inspection session can discover
many errors in a system.
2. Incomplete versions of a system can be inspected without additional costs. If a
program is incomplete, then you need to develop specialised test harnesses to test the
parts that are available. This obviously adds to the system development costs.
3. As well as searching for program defects, an inspection can also consider broader
quality attributes of a program such as compliance with standards, portability and
maintainability. You can look for inefficiencies, inappropriate algorithms and poor
programming style that could make the system difficult to maintain and update.
4. 1. Integration testing:
The process of system integration involves building a system from its components and
testing the resultant system for problems that arise from component interactions. The
components that are integrated may be off-the-shelf components, reusable components
that have been adapted for a particular system or newly developed components. For many
large systems, all three types of components are likely to be used. Integration testing
checks that these components actually work together, are called correctly and transfer the
right data at the right time across their interfaces.
Top-down integration: the overall skeleton of the system is developed first, and
components are added to it.
Bottom-up integration: first integrate infrastructure components that provide
common services, such as network and database access, then add the functional
components.
A major problem that arises during integration testing is localising errors. There are
complex interactions between the system components and, when an anomalous output is
discovered, you may find it hard to identify where the error occurred. To make it easier to
locate errors, you should always use an incremental approach to system integration and
testing.
In the example shown in figure, A, B, C and D are components and n to T5 are related
sets of tests of the features incorporated in the system. n, T2 and T3 are first run on a
system composed of component A and component B (the minimal system). If these
reveal defects, they are corrected. Component C is integrated and n, T2 and T3 are
repeated to ensure that there have not been unexpected interactions with A and B. If
problems arise in these tests, this probably means that they are due to interactions with
the new component. The source of the problem is localised, thus simplifying defect
location and repair. Test set T4 is also run on the system. Finally, component D is
integrated and tested using existing and new tests (T5).
2. Release Testing:
Release testing is the process of testing a release of the system that will be distributed to
customers. The primary goal of this process is to increase the supplier's confidence that
the system meets its requirements. If so, it can be released as a product or delivered to the
customer. Release testing is usually a black-box testing process where the tests are
derived from the system specification. The system is treated as a black box whose
behavior can only be determined by studying its inputs and the related outputs. Another
name for this is functional testing because the tester is only concerned with the
functionality and not the implementation of the software. Figure illustrates the model of a
system that is assumed in black-box testing.
The tester presents inputs to the component or the system and examines the
corresponding outputs. If the outputs are not those predicted (i.e., if the outputs are in set
Oe) then the test has detected a problem with the software. Ie: inputs that have a high
probability of generating system failures.
UNIT 8
1. Explain factors governing staff selection. [Dec 2015, June 2013] [10M]
Problem solving ability: This is very important for software engineers who constantly
have to solve technical problems. However, it is almost impossible to judge without
knowing the work of the potential team member.
Educational background: This may provide an indicator of what the candidate knows and
his or her ability to learn. This factor becomes increasingly irrelevant as engineers gain
experience across a range of projects.
Communication ability: Project staff must be able to communicate orally and in writing
with other engineers, managers and customers.
Attitude: Project staff should have a positive attitude toward their work and should be
willing to learn new skills. This is an important attribute but often very difficult to assess.
Maslow (Maslow 1954) suggests that people are motivated by satisfying their needs and
that needs are arranged in a series of levels. The lower levels of this hierarchy represent
fundamental needs for food, sleep, and so on, as well as the need to feel secure in an
environment. Social needs are concerned with the need to feel part of a social grouping.
Esteem needs are the need to feel respected by others, and self-realisation needs are
concerned with personal development. Human priorities are to satisfy lower-level needs
such as hunger before the more abstract, higher-level needs.
Ensuring the satisfaction of social, esteem and self-realisation needs is most significant
from a management point of view.
l. To satisfy social needs, you need to give people time to meet their co-workers and to
provide: places for them to meet. This is relatively easy when all of the members of a
development team work in the same place but, increasingly, team members are not
located in the same building or even the same town or state.
They may work for different organizations or from home most of the time.
Electronic communications such as e-mail and teleconferencing may be used to support
this remote working. However, my experience with electronic communications is that
they do not really satisfy social needs. If your team is distributed, you should arrange
periodic face-to-face meetings so that people experience direct interaction with other
members of the team. Through this direct interaction, people become part of a social
group and may be motivated by the goal and priorities of that group.
2. To satisfy esteem needs, you need to show people that they are valued by the
organization. Public recognition of achievements is a simple yet effective way of doing
this. Obviously, people must also feel that they are paid at a level that reflects their skills
and experience.
3. Finally, to satisfy self-realization needs, you need to give people responsibility
for their work, assign them demanding (but not impossible) tasks and provide a training
programme where people can develop their skills.
3.Describe with block diagram, SEI people- CMM. [Dec 2015, June 2013, June
2015] [10M]
The Software Engineering Institute (SEI) in the United States is engaged in a long term
programme of software process improvement. Part of this programme is the Capability
Maturity Model (CMM) for software processes. The P-CMM can be used as a framework
for improving the way in which an organisation manages its human assets.
4. What are the factors affecting software pricing? What are the two types of metric
used? Explain. [Jan 2014, Dec 2014] [10M]
A number of algorithmic models have been proposed as the basis for estimating the
effort, schedule and costs of a software project. These are conceptually similar but use
different parameter values. The model that I discuss here is the COCOMO model.
The COCOMO model is an empirical model that was derived by collecting data from a
large number of software projects. These data were analysed to discover formulae that
were the best fit to the observations. These formulae link the size of the system and
product, project and team factors to the effort to develop the system.
Ii is chosen to use the COCOMO model for several reasons:
1. It is well documented, available in the public domain and supported by public domain
and commercial tools.
2. It has been widely used and evaluated in a range of organisations.
3. It has a long pedigree from its first instantiation in 1981 (Boehm, 1981), through a
refinement tailored to Ada software development (Boehm and Royce,
1989), to its most recent version, COCOMO II, published in 2000 (Boehm,
et al. 2000),