Sie sind auf Seite 1von 8

1. Which are the design goals of WebApps?

Consistency
–Content should be constructed consistently
–Graphic design (aesthetics) should present a consistent look across all parts of the WebApp
–Architectural design should establish templates that lead to a consistent hypermedia structure
–Interface design should define consistent modes of interaction, navigation and content display
–Navigation mechanisms should be used consistently across all WebApp elements
Identity
–Establish an “identity” that is appropriate for the business purpose
Robustness
–The user expects robust content and functions that are relevant to the user’s needs
Navigability
–designed in a manner that is intuitive and predictable
Visual appeal
–the look and feel of content, interface layout, color coordination, the balance of text, graphics and other
media, navigation mechanisms must appeal to end-users
Compatibility
–With all appropriate environments and configurations

2. What is MVC? Eplain it.


The Model-View-Controller (MVC) is an architectural pattern that separates an application into three main logical
components
1. The model represents the data, and does nothing else. The model does NOT depend on the controller or the
view.
2. The view displays the model data, and sends user actions (e.g. button clicks) to the controller. The view
can:
○ be independent of both the model and the controller; or
○ actually be the controller, and therefore depend on the model.
3. The controller provides model data to the view, and interprets user actions such as button clicks. The
controller depends on the view and the model. In some cases, the controller and the view are the same
object.

3. What is Repository Architecture?


Sub-systems must exchange data. This may be done in two ways:

1. Shared data is held in a central database or repository and may be accessed by all sub-systems;
2. Each sub-system maintains its own database and passes data explicitly to other sub-systems.

When large amounts of data are to be shared, the repository model of sharing is most commonly used a this is an
efficient data sharing mechanism.

4. What are the repository features?


Versioning -- saves all of these versions to enable effective management of product releases and to permit
developers to go back to previous versions

Dependency tracking and change management -- The repository manages a wide variety of relationships among the
data elements stored in it.
Requirements tracing -- Provides the ability to track all the design and construction components and deliverables
that result from a specific requirement specification

Configuration management -- Keeps track of a series of configurations representing specific project milestones or
production releases. Version management provides the needed versions, and link management keeps track of
interdependencies.

Audit trails -- establishes additional information about when, why, and by whom changes are made.

5. What is software configuration?


Software configuration management is the task of tracking and controlling changes in the software, part of the larger
cross-disciplinary field of configuration management. SCM practices include revision control and the establishment
of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a
configuration is working well, SCM can determine how to replicate it across many hosts

6. What is integration testing. Explain different types of integration testing?


Integration testing tests integration between components, interactions to different parts of the system such as an
operating system, file system and hardware or interfaces between systems. Integration testing is a key aspect of
software testing.

Top down - the testing takes place from top to bottom, following the control flow or architectural structure.
Additionally, components or systems are substituted by stubs.

Buttom up - all the modules at the lower level of the software are tested with higher modules until all the modules
are tested. Moreover, the bottom up testing takes place from the bottom of the control flow to upwards. Unlike top-
down approach, here the components or systems are substituted with driver.

Sandwich testing is a culmination of both incremental as well as non incremental integration testing, wherein
Bottom-Up approach is focused on middle to top layer, Top-Down approach is concerned about layers from middle
to downwards and the Big Bang approach is followed for the middle layer. This type of testing combines the
advantages of all the three approaches and is mainly used to test large projects.

7. What is Unit Testing? Explain V&V.


Unit testing, a testing technique using which individual modules are tested to determine if there are any issues by
the developer himself. It is concerned with functional correctness of the standalone modules.
The main aim is to isolate each unit of the system to identify, analyze and fix the defects.
Verification refers to the set of tasks that ensure that software correctly implements a specific function.
Validation refers to a different set of tasks that ensure that the software that has been built is traceable to
customer requirements. Another way:
Verification: "Are we building the product right?" Validation: "Are we building the right product?
8. Regression, Exhaustive, alpha-beta testing
SMOKE TESTING, also known as “Build Verification Testing”, is a type of software testing that
comprises of a non-exhaustive set of tests that aim at ensuring that the most important functions work.
The result of this testing is used to decide if a build is stable enough to proceed with further testing.The
term ‘smoke testing’, it is said, came to software testing from a similar type of hardware testing, in
which the device passed the test if it did not catch fire (or smoked) the first time it was turned on .Smoke
testing is normally used in Integration Testing, System Testing and Acceptance Testing levels.
Regression -- Software maintenance is an activity which includes enhancements, error corrections, optimization and
deletion of existing features. These modifications may cause the system to work incorrectly. This testing is done to
make sure that new code changes should not have side effects on the existing functionalities. It ensures that the old
code still works once the new code changes are done.

Exhaustive -- Exhaustive testing is a testing or quality assurance approach in which all possible combinations of
scenarios and use/test cases are used for testing.

9. Explain the white box and black box testing.


White Box – is a method of testing software that tests internal structures or workings of an application, as opposed
to its functionality. Goal is to ensure that all statements and conditions have been executed at least once.

Black Box - is a method of software testing that examines the functionality of an application without peering into its
internal structures or workings. This method of test can be applied virtually to every level of software testing: unit,
integration, system and acceptance.

10. Explain why design conflicts might arise when designing an architecture for which both
availability and security requirements are the most important non-functional requirements.
The architecture of a soft sys is based on particular pattern or style. These patterns capture the essence of an
architecture that has been used in diff software. When designing arch then conflicts may arise at both availability
and security requirements. These are the most important non functional requirements.
Security: If security is a critical req, a layered structure for the architecture should be used, with the most critical
assets protected in the innermost layers, with a high level of security validation applied to these layers.
Availability: If availability is a critical requirement, the architecture should be designed to include redundant
components so that it is possible to replace and update components without stopping the system
There is a potential conflict between some architectures. For xample, using large components improves performance
and using small, fine grain components improves maintainability. If both performance and maintainability are
important sys req, then some compromise must be found. This can be achieved by using different architectural or
styles for different parts of the system.
11. Explain why you normally use several architectural patterns when designing the architecture of
a large system.(sommerville book)
Normally while designing arch of a large systems, several arch patterns are used. It is so because a large system
constitutes several sub systems like database system, server, customer management etc. Designing is done by
dividing the total architecture into subsystems. As each system differs from the other each sys requires different arch
patterns. A single arch pattern may not be sufficient to represent the entire view of the system in a detailed manner.
So using diff patterns a large sys will be represented.

12. What are the benefits of involving users in release testing at an early stage in the testing
process? Are there disadvantages in user involvement?
Benefits:
• As the system release is for customers and users, they can easily identify the modifications needed.
• Helps in getting the views of the users and the modifications needed from the user’s perspective.
Disadvantages:
• May not get a better feedback as the views and ideas of users vary from person to person.
• May increase the effort of testing as the users may not have clear view of the system
• Testing perspective may sometimes be deviated to some other view.

13. Explain why keeping all members of a group informed about progress and technical decisions in
a project can improve group cohesiveness.
In a cohesive group, all members have the same fundamental objective and, generally, recognize that this takes
priority over other individual objectives. When there is good information exchange and a culture where problems
and difficulties are shared, individuals are much more likely to be able to keep this common objective in sight and to
work together to solve the problems. If information is hidden, there is a tendency for people to think that those
hiding the information are doing so because of personal objectives and so they are seen as not being a subscriber to
the overall group objective. This is a particular problem when the person hiding the information is the group leader -
if the group leader does not promote a culture of openness, an atmosphere of suspicion is likely to arise. Of course,
this doesn’t mean that everyone has to know everything. Information hiding is important. However, if people know
that the information is there if they need to know it, then they will not be suspicious.

14. List the factors affecting cost of software maintenance?


Module Independence
Programming Language
Programming Style
Program Validation and Testing
Quality of Program Documentation
Configuration Management Techniques
Application Domain
Staff Stability
Age of the System
Dependence of the System on the External Environment
Hardware Stability

15. What are the estimation techniques used in a Software project? Explain two of them.
● Past (similar) project experience
● Conventional estimation techniques
○ task breakdown and effort estimates
○ size (e.g., FP) estimates
● Empirical models
● Automated tools

Conventional Methods:
LOC/FP Approach
● compute LOC/FP using estimates of information domain values
● use historical data to build estimates for the project

16. Explain why first law of Software Engineering is true?


“No matter where you are in the system life cycle, the system will change, and the desire to change it will persist
throughout the life cycle”
Why true?
New business or market conditions which cause changes in product requirements or business rules
New customer needs that demand modification of data, functionality or services delivered by the system
Reorganization and/or business downsizing that changes priorities and team structures
Budgetary or scheduling constraints that cause a redefinition of the system

17. Why Maintenance is very important? Explain the types of maintenance.


Corrective Maintenance
• Focused on fixing failures
• Is a reactive process : failures and their associated faults generally need to be corrected either immediately
or in the near future
• Failures vary in their cost to correct
• Coding - usually relatively cheap
• Design - more expensive as they may require changes to several program components
• Requirements - most expensive - may require extensive system redesign
• Design and Requirements are the source of approximately 80% of failures
• Fixing a fault has a 20 to 50% chance of introducing another fault

Adaptive Maintenance
The evolution of the system to meet the needs of the user and the business
Caused by:
• internal needs
• external competition
• external requirements e.g. changes in law
Essentially, we are introducing new requirements to the system therefore it should be treated like a new
development in our approach and methods

Perfective Maintenance
Perfective is about improving the quality of a program that already works. Aim to achieve:
• reduced costs in using the system
• increase maintainability of the system
• more closely meet the users’ needs
Includes all efforts to polish or refine the quality of the software or the documentation
Important that the potential benefits of the perfective maintenance outweigh the costs of the maintenance and the
opportunity costs of improvements elsewhere or using the resources on new developments.
Therefore before performing perfective maintenance, one should go through an analysis process
Nevertheless, a little perfective maintenance can have dramatic effects

Preventative Maintenance
Can be seen as radical perfective maintenance or as an alternative to maintenance
More commonly known as Software Re-engineering
Taking a legacy system and converting its structure or converting to a new language
Old system starts as a specification for the new system
Common method now is known as wrappers where an entire system is placed in an OO wrapper and treated as one
large object

18. Why is maintenance so costly? Explain the Maintenance Process.


- Software by its nature is constantly evolving.
- Just because you bought the software doesn’t mean you – or the rest of your staff – know how to use it
well.
- The worst thing that can happen to a software user is to learn that the vendor has gone out of business.
- Developing software is an expensive proposition
- When things go wrong, you need someone to call.

Change Management
Uniquely identify, describe and track the status of all change requests
Impact Analysis
identifies all systems and system products affected by a change request
makes an estimate of the resources needed to effect the change
analyses the benefits of the change
System Release Planning
to establish the schedule and contents of a system release
don’t want each change request released as they are processed
Change Implementation
Design Changes
Coding
Testing - must perform regression testing
System Release includes
documentation
software
training
hardware changes
data conversion

19. Factors Affecting Maintenance Costs. Differences between Maintenance and New Development
Development - refers to the primary implementation of new projects. Once an initial development project is
complete, and the clients/stakeholders have accepted it, then you will typically move into a new phase--either
maintenance or enhancement.

Maintenance - refers to ongoing administration of accepted and "completed" functionalities/features. For instance,
you may have a maintenance contract to: provide ongoing support to end-users, to fix previously unknown bugs in
the accepted functionality, to ensure that the server doesn't go down, and so on.

20. Types of Maintenance.( pyetja 17)


Lehman’s Laws of Software Change.

1. Continuing Change — an E-type system must be continually adapted or it becomes progressively less
satisfactory.
2.Increasing Complexity — as an E-type system evolves, its complexity increases unless work is done to maintain or
reduce it.[4]
3.Self Regulation — E-type system evolution processes are self-regulating with the distribution of product and
process measures close to normal.
4.Conservation of Organisational Stability (invariant work rate)" — the average effective global activity rate in an
evolving E-type system is invariant over the product's lifetime.
5.Conservation of Familiarity — as an E-type system evolves, all associated with it, developers, sales personnel and
users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive
growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.[4]
6.Continuing Growth — the functional content of an E-type system must be continually increased to maintain user
satisfaction over its lifetime.
7.Declining Quality" — the quality of an E-type system will appear to be declining unless it is rigorously maintained
and adapted to operational environment changes.[5]
8.Feedback System— E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems
and must be treated as such to achieve significant improvement over any reasonable base

21. Explain the activities of software reengineering. Explain Reverse Engineering.


Abstraction level – ideally want to be able to derive design information at the highest level possible
Completeness – level of detail provided at a given abstraction level
Interactivity – degree to which humans are integrated with automated reverse engineering tools
Directionality – one-way means the software engineer doing the maintenance activity is given all information
extracted from source code, two-way means the information is fed to a reengineering tool that attempts to regenerate
the old program
Extract abstractions – meaningful specification of processing performed is derived from old source code

Reverse engineering, also called back engineering, is the process by which a man-made object is deconstructed to
reveal its designs, architecture, or to extract knowledge from the object

22. Explain Software Development Triangle/Pyramid.


The Project Management Triangle (called also the Triple Constraint, Iron Triangle and "Project Triangle")
is a model of the constraints of project management. It contends that:
The quality of work is constrained by the project's budget, deadlines and scope (features).
The project manager can trade between constraints.
Changes in one constraint necessitate changes in others to compensate or quality will suffer.

Das könnte Ihnen auch gefallen