Search This Blog

Tuesday 22 February 2011

SOFTWARE_ENGINEERING_TWO_MARKS


  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.


  1. 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
  • Current level of each module, including source and object code
  • Current level of each test case, including source and object code
  • The current level of any special test or operational data
  • 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
  1. Preliminary User Manual
  2. Design specification
a)      Data Design Description
b)      Architectural design specification
c)      Module design description
d)      Interface design descriptions
e)      Object descriptions
  1. Source code listing
  2. Test spcification
a)      Test plan and procedures
b)      Test cases and recorded results
  1. Operation and Installation Manuals
  2. Executed Program
a)      Module executable code
b)      Linked Modules
  1. Database Descriptions
a) Schema file structure
b) Initial content
  1. As-built User manual
  2. 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
 
  1. Integration tests
It verifies the interfaces between system parts (modules, components, and subsystems)
  1. External function tests
It verifies the external system functions, as stated in the external specifications
  1. Regression tests
It runs a subset of previously executed integration and function tests to ensure that program
  1. System tests
It verifies and/or validate the system to its initial objectives
  1. Acceptance tests
It validates the system or program to the user’s requirements
  1. 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.






















No comments: