Featured

    Featured Posts

Microprocessing and Interfacing Dec 2016 sample paper Code-EE-309-F



Microprocessing and Interfacing
Dec 2016
Paper Code-EE-309-F

Q.1

Q.2

Q.3
(b) What is the functioning of timing and control unit in 8085 microprocessor? Discuss all its signals in details.

Q.4
(b) Discuss Pipelining .

Q.5
(b) How physical address is computed in 8086 microprocessor ?

Q.6. Write a simple assembly program to subtract two memory location, where each memory location is one byte wide.

Q.7
(a) Write short notes on directives and operators.
(b) Write a 8086 assembly language program to find largest number in data array.

Q.8. Explain 8259 interrupt controller with the help of block diagram.

Q.9. Explain the following :
(a) 8253/8254 programmable interval timer.
(b) Instruction register and priority resolver.

Microprocessor and Interfacing B.Tech 5th semester sample paper Dec-2011


       Sample papers are the best source of knowledge for the students towards their preparation of semester examinations. Students will find all the sample papers on this great source of education. We provide almost all the sample papers here in the form notes and in PDF formats. Here is one of the sample paper of B.Tech. Microprocessor and Interfacing is one of the subject students will study or studying in 5th or 6th semester. Students can prepare here with this great source of knowledge. Students can refer this website for their needs of looking for previous sample papers. We even provide the solutions of these sample papers in best possible way. So keep watching this space for more and latest B.Tech sample papers of all the universities  ( MDU, UPTU, KTU, DTU, RTU,).


Microprocessor and InterfacingDec 2011Paper Code: EE-309-F


Note : Attempt five questions in all, selecting one question from each unit. Q. 1 is compulsory.

Q.1(a). Define memory segmentation.
      (b). What are data transfer instructions and arithmetic instructions ?
       (c). Specify the 8085 signals that are used to enable an input port.
      (d). Explain why the number of output ports in the peripheral-mapped I/O is restricted to 256 ports?
      (e). What operation can be performed by using the instruction ADD A ?
      (f). Define addressing modes.
      (g). Explain Direct Memory Access.
View solution of Q.1. here







Microprocessor and Interfacing previous solved sample papers


       Sample papers are the best source of knowledge for the students towards their preparation of semester examinations. Students will find all the sample papers on this great source of education. We provide almost all the sample papers here in the form notes and in PDF formats. Here is one of the sample paper of B.Tech. Microprocessor and Interfacing is one of the subject students will study or studying in 5th or 6th semester. Students can prepare here with this great source of knowledge. Students can refer this website for their needs of looking for previous sample papers. We even provide the solutions of these sample papers in best possible way. So keep watching this space for more and latest B.Tech sample papers of all the universities  ( MDU, UPTU, KTU, DTU, RTU,)
Sample papers, MDU B.Tech sample papers of microprocessor and interfacing, 5th semester sample papers, MDU B.Tech sample papers of 5th semester, microprocessor and interfacing 5th semester solved sample papers, Microprocessor and Interfacing MDU B.tech Solved question papers


What is CASE ? How it supports software life cycle ?


What is CASE ? How it supports software life cycle ?

           CASE stands for Computer Aided Software Engineering.  CASE is a tool which aids a software engineering and develop software.  The workshop for software engineering is called an Integrated Project Support Environment (IPSE) and the tool set that fills the workshop is called an Integrated Project Support Environment (IPSE) and the tool set that fills the workshop is called CASE.
       CASE is a computer aided software engineering technology.  CASE is an automated support tool for the software engineers in any software engineering processes :
       Software engineering mainly includes the following processes :

  • Translation of user needs into software requirements.
  • Transaction of software requirements into design specification.
  • Implementation of design into code.
  • Testing of the code.
  • Documentation.
      There are various types of support that CASE provides during the different phases of a software life cycle.

1. Prototyping Support :
               The prototyping is useful to understand the requirements of complex software products, to market new ideas and so on.  The prototyping CASE tools requirements are as follows:

  • Define user interaction
  • Define the system control flow
  • Store and retrieve data required by the system
  • Incorporate some processing logic.
Few features, which are supported by prototyping tools, are:

  • Main use of prototyping CASE tool is developing Graphical User Interface (GUI) development. The user should be allowed to define all data entry forms, menus and control.
  • Integrate well with the data dictionary of a CASE environment.
  • The user should be able to define the sequence of states through which a created prototype can run.
  • The prototype should support mock up run of the actual system and management of the input and output data.
  • It should be able to integrate with the external user-defined modules written in high level languages.



2. Structured Analysis and Design :  A CASE tool should support one of more of the structured analysis and design techniques.  It should also support making of the fairly complex diagrams and preferably through a hierarchy of levels.  The tool must also check the incompleteness, inconsistencies and anomalies across the design and analysis through all levels of analysis hierarchy.
         Analysis and design tools enable a software engineer to create models of the system to be built.  The models contain a representation of data, function, behaviour and characterizations of data, architectural, component level, and interface design.  By performing consistency and validity checking on the models, analysis and design tools provide a software engineer with some degree of insight into the analysis representation and help to eliminate errors before they propagate into the design, or worse, into implementation itself.

3. Code Generation :  A support expected from a CASE tool during the code generation phase comprise the following:

  • The CASE tool should support generation of module skeletons or templates in one or more popular programming languages.
  • The tool should generate records, structures, class definition.
Why CASE approach is recommended in case for large complex software solution ? 

 

What are the major phases in the spiral model of software development?


What are the major phases in the spiral model of software development?
         There are six major phases in the spiral model of software development.  These are :

  1. Customer communication
  2. Planning
  3. Risk analysis
  4. Mode-ling / construcrion
  5. Engineering
  6. System Evaluation
Communication :  Communication is one of the very important activities in software development, if there is good communication between client and developer, then the probability of failure of software is less, because software developer make effective communication to client, and he/she understand the requirement of software project.

Planning :  In this phase first of all, each and every activities depends upon the requirements of the customer/client, then estimate the schedule of each and every activities, when first activity start and how much time it will require to solve it, then estimate the budget of each and every activity.  Then develop Software Requirement Specification.

Risk Analysis :  Concerned with both technical and management risk.


Modeling :  The goal of the design phase is to transform the requirement specified in the software Requirement Specification document into a structure that is suitable for the implementation in some programming language.
       In the technical term, during the design phase of the software architecture is derived from software requirement specification document.
      The design phase of the software development is most critical factor affecting the quality of the software.
      Output of this phase is the design document :
      Design activity divided into two separate phases :

  1. System design : Some time called top level design, aim to identify the module, how many module needed, how they interconnect to each other and also specify each and every module specification.
  2. Detailed Design :  Internal logic of each and every module is specified during it.
     Engineering :  Once the design phase is complete, next phase is coding, it is another very important activity in software development i.e design must be translated into machine readable form.  It directly affect both testing and maintenance.  Well written code, can reduce the testing and maintenance effort, once the coding is complete, next phase is testing.
       Testing process focus and internal logic of the software, assuming that all statement have been tested functional, i.e conducting the test to uncover the error and ensure that defined input will produced actual result, that agree with result.

     System evaluation :  After the software install towards the customer side, obtain the feedback to them, either they will face problem during execution of the software project.  If there is any modification required, that will done, and take feedback until or unless customer not satisfy according to requirement specification.
        The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks.  After major risks have been addressed, the spiral model terminates as a waterfall model.  Spiral iterations involve six step :

  1. Determine objectives, alternatives and constraints.
  2. Identify and resolve risks
  3. Evaluate alternatives
  4. Develop the deliverable's for that iteration and verify that they are correct.
  5. Plan the next iteration.
  6. Commit to an approach for the next iteration.

The role of Formal Technical Review (FTR) as a quality assurance activity in software engineering concepts.


Formal Technical Review (FTR):

               The FTR is a software is a software quality assurance activity with the objectives to uncover errors in function, logic or implementation for any representation of the software, to verify that the software under review meets its requirements, to ensure that the software has been represented according to predefined standards, to achieve software that is developed in a uniform manner and to make projects more manageable.  FTR  activities include walk-through, inspection and round robin review and other technical assessments.
             Review meeting is important  form of FTR and there are some essential parameters for the meeting such as there should be reasonable number of persons conducting the meeting and that too after each one of them has done his/her homework i.e some preparation and the meeting should not be carried out very long which may lead to wastage of time but rather for duration just enough to churn out some constructive results.  FTR is effective when a small and specific part of the overall software is under scrutiny.  It is easier and more productive to review in small parts like each module one by one rather than to review the whole thing in one go.  The target of the FTR is on a component of the project, a single module.

Record Keeping and Reporting :  Record keeping and reporting are another quality assurance activities.  It is applied to different stages of software development.
       During the FTR, it is the responsibility of reviewer (or recorder) to record all issues that have been raised.  At the end of review meeting, a review issue list summarizes all issues, is produced.  A simple review summary report answers the following questions.
     A review summary report answer the following questions :

  1. what was reviewed?
  2. who reviewed it?
  3. what were findings an conclusions?

 
FTR can be conducted as follows :

Before the FTR :

  1. Ask for what you want.  A written is helpful, in which you prioritize your needs, make specific requests from your reviewers about how you want them to read your materials and the kind of critique you want.
  2. Limit the scope of materials to be reviewed.  Be clear about the quality, content, and focus of the feedback you would like to receive.  Indicate whether you want them to write a list of issues, put comments on the document, or whatever.
  3. Don't demand more than 2 hours of preparation time from your reviewers.
  4. Arrange delivery of the work product in advance so reviewers have adequate time to prepare.
  5. Reviewers:  Spend no more than 2 hours individually critiquing the work product.
During the FTR :

  1. Moderator, usually QA leader, is responsible for running the meeting and orchestrating how is issues are to be presented.
  2. Reviewers raise issues based on their advance preparation.
  3. Get the big problem issues on the table early.  Don't get lost in minutely small clerical details.
  4. Identify problems, don't solve them.
  5. Focus on material, not the producer.
  6. Elicit questions, don't answer them.
  7. Don't explain how your product works.  An FTR is not a product demo.
  8. Watch the clock and keep momentum to get through all the issues in the allotted time.
  9. Recorder actively records all issues raised.
At the end of the FTR:  Reviewers must make a decision :

  • Accept - the product is acceptable as is.
  • Rework - accept the product provisionally, minor errors have been encountered and must be corrected, but no additional review will be required.
  • Reject - the product has severe errors.  You need to overhaul the item and schedule another FTR.
After the FTR:

  • Write up the issues list.
  • Examine the issues raised, determine which to take action on.
  • Assign each issue to someone as an action item and revise work product as neede.
  • Write review summary report.
  • Have reviewers sign off on summary report, indicating proper corrective action has been taken for each issue.
  • Include signed report in deliverable.

What do you mean by software configuration management ?


Software configuration management :

                       Software configuration management (SCM) is one of the foundations of software engineering.  It is used to track and manage the emerging product and its versions.  This is to assure quality of the product during development, and operational maintenance of the product.  SCM ensures that all people involved in the software process know what is being designed, developed, built, tested, and delivered.

Definitions : Different people perceive Software Configuration Management differently.  The following are few perceptions of several people about SCM in the form of definitions.
  1. Software Configuration Management (SCM) is the art of identifying organizing and controlling modifications to the software being built by a programming team.  The goal is to maximize productivity by minimizing mistakes.
  2. Software Configuration Management is the process of defining and implementing a standard configuration, that results into the primary benefits such as easier setup and maintenance, less down time, better integration with enterprise management, and more efficient and reliable backups.
  3. Software Configuration Management is the process concerned with the development of procedures and standards for managing an evolving software system product.
  4. Software Configuration Management is the ability to control and manage change in a software project.
Importance of SCM :  SCM gives developers a means to coordinate the work of numerous people on a common product whether they work in close proximity or over a wide geographical area.  Without a good SCM plan, projects become increasingly difficult to control and can reach the point where the project has to be discontinued because it can not be fixed.  There is an impact of software life cycle model on software configuration management
Goals :  The following are the major goals of software configuration management :
  • Software configuration management activities are planned.
  • Selected software work products are identified, controlled and available.
  • Change to identified software work products are controlled.
  • Affected groups and individuals are informed of the status and content of software baseline.

Difference b/w verification Vs validation and executable and non-executable testing


Difference between validation and verification, verification vs validation, difference between executable and non-executable testing, executable vs non-executable testing, execution based testing vs execution based testing.

(a) Difference between verification and validation :

Verification
Validation
Verification ensures that the product is designed to deliver all functionality to the customer
Validation ensures that functionality is the intended behavior of the product.
It involves reviews and meetings to evaluate documents, plans, code, requirements and specifications.
It involves actual testing and takes place after verification is completed
It evaluates documents, plans, code, requirements and specifications.
It evaluates the product itself.
Inputs are checklists, issues lists, inspection meetings, reviews and meetings.
It is the actual testing of the actual product.
Output is a nearly perfect set of documents, plans specifications and requirements document.
Output is a nearly perfect product.


Difference between validation and verification, verification vs validation, difference between executable and non-executable testing, executable vs non-executable testing, execution based testing vs execution based testing.

(b) Executable and Non-executable :

(i)  Execution based testing : In this type of testing, the modules are run against test cases.  Following are the two ways of systematically constructing test data to test a module :
  1. Black-Box testing :  The code itself is ignored, the only information used in designing test cases is the specification document.
  2. White-Box Testing :  The code itself is tested, without regard of the specifications.
(ii)  Non-execution based testing :  The non-execution based testing relies on fault detection strategy.  The fault-detecting power of these non-execution based techniques leads to rapid, through, and early fault detection. The additional time required for code reviews is more that repaid by the increased productivity due to fewer faults at the integration phase.
       In general, non-execution based code testing is less expensive than execution-based testing because :
  1. Execution-based testing (running test case) can be extremely time-consuming, and 
  2. Reviews lead to detection of faults earlier in the life cycle.
Non-execution based testing is also known as static testing (or static program analysis).

 

Define followings : Abstraction, Refinement, Functional Independence, Information Hiding & explanation of the complete software architectural design process.


Define followings : Abstraction, Refinement, Functional Independence, Information Hiding.

Abstraction :   
                          It aims to reduce duplication of information in a program ( usually with emphasis on code duplication) whenever practical by making use of abstractions provided by the programming language or software libraries.  Abstraction is one of the most important techniques in software engineering and is closely related to two other important techniques, encapsulation and information hiding.  All three techniques are used to reduce complexity.

Refinement :
                        Refinement is a generic term of computer science that encompasses various approaches for producing correct computer programs and simplifying existing programs to enable their formal verification.  In formal methods, program refinement is the verifiable transformation of an abstract(high level) formal specification into a concrete(low level) executable program. Step-wise refinement allows this process to be done in stages.

Functional Independence :
                                               By the term, functional independence, we mean that a module performs a single task and needs very little interaction with other modules.
       A module the is highly cohesive and also has low coupling with other modules is said to be functional independent of the other modules.  It is designing the modules in such a way that each module has s specific functional requirements.  It is measured using cohesion and coupling.

Information Hiding : 
                                    Information hiding is shielding the internal details of a module's processing from other modules.  For example, most procedural programming languages ( like Pascal and c ) have static scope  rules, making local variables in sub-programs inaccessible outside the sub-program.  This scoping mechanism hides local variables inside sub-programs.
       The principle of Information Hiding is of fundamental importance in software design and is given as :
                 
Modules should hide private information

Information hiding is good for both the module that hides its internals and for the rest of the program.

(b).  Architectural design process :

                         Software architecture is the design process for identifying the sub-system making up a system and the framework for sub-system control and communication is a architectural design.  The output of this design process is a description of the software architecture.
  • It is an early stage of the system design process.
  • Represents the link between specification and design processes.
  • Often carried out in parallel with some specification activities.
  • It involves identifying major system components and their communications.

Architecture and system characteristics :

  1. Performance :  Localise critical operations and minimise communications. Use large rather than fine-grain components.
  2. Security :  Use a layered architecture with critical assets in the inner layers.
  3. Safety :  Localise safety-critical features in a small number of sub-systems.
  4. Availability :  Include redundant components and mechanisms for fault tolerance.
  5. Maintainability :  Use fine-grain, replaceable components.

Architectural design decisions :

  • Is there a generic application architecture that can be used ?
  • How will the system be distributed ?
  • What architectural styles are appropriate ?
  • How will the system be decomposed into modules?
  • What control strategy should be used?
  • How will the architectural design be evaluated?
  • How should the architecture be documented?
Architecture reuse : Systems in the same domain often have similar architectures that reflect domain concepts.  Application product lines are built around core architecture with variants that satisfy particular customer requirements.

Architectural styles :  The architectural model of a system may conform to a generic architectural model or style.  An awareness of these styles can simplifying problem of defining system architectures.  However, most large systems are heterogeneous and do not follow a single architectural style.

Architectural models :
  • Used to document an architectural design.
  • Static structural model that shows the major system components.
  • Dynamic process model that shows the process structure of the system.
  • Interface model that defines sub-system interfaces.
  • Relationships model such as a data-flow model that shows sub-system relationships.
  • Distribution model that shows how sub-systems are distributed across computers.


 

Principles of software engineering CSE- 302-F May 2012 MDU B.tech Solved question paper


MDU B.Tech May 2012 Solved question papers of Software engineering.

Principles of software engineering

Paper code CSE-302-F

May 2012

Section A

Q.1.
(a) Define software engineering.
(b) what is data dictionary ?
(c) what do you mean by data modeling ? List out the factors of data modeling.
(d) Differentiate between database and data warehouse.
(e) Define basis path testing.
(f) List out of various methods for finding the cyclomatic complexity.
(g) What do you mean by cost impact of software defects.
(h) What steps are required to perform statistical SQA.
(i) Define CASE tools.
(j) List out the possible errors of black box testing.
View solution here

Q.2. 
(a) What is meant by Software Process ? Explain in detail.
(b) Explain the iterative enhancement model with the help of suitable example.
Ans. View solution here

Q.3.
(a)What are project metrics ? Differentiate between size oriented metrics and function oriented metrics ?
(b) Discus the common sources and types of risks in software development projects and strategies to deal with them ?
Ans. View solution here

Section B

Q.4. Explain the various types of cohesion and coupling in detail. Which one is the best and which one is the worst among them in case of both cohesion and coupling ?
Ans. View solution here

Q.5.
(a) Define the following terms :  Abstraction, Refinement, Functional Independence, Information Hiding.
(b) Explain the complete architectural design process.
 Ans. View solution here

 

Section c

Q.6.
(a) What is software testing ? Why do we test ? What are the different testing principles ?
(b) Describe the equivalence class partitioning as used in software testing ?
Ans. View solution here

Q.7.
(a) Differentiate between verification and validation ?
(b) What do you mean by executable and non executable testing ?
Ans. View solution here

Section D

Q.8.
(a) What do you mean by software configuration management ?
Ans. View solution here
(b) Describe the role of Formal Technical Review (FTR) as a quality assurance activity. How is it conducted ?
Ans. View solution here

Q.9.
(a) Explain SQA activities in detail.
Ans. View solution here
(b) Why CASE approach is recommended in case for large complex software solution ? Comment how CASE approach affects the following :
(i) Documentation.
(ii) Programming Effort.
Ans. View solution here

MDU B.Tech First year Sample Papers All Semesters Papers Free download


MDU B.E/B.Tech Sample Papers in PDF Download Here

Download free sample papers of MDU B.E/B.Tech 1st year common semester solved papers.  All the previous solved sample papers can be downloaded from here with the links provided.

1. Essentials Of Communication 1st Semester Solved Sample Paper.
2. Fundamentals Of Computer Programming Solved Sample Papers.
3. Manufacturing Process Solved Sample Papers.
4. Engineering Physics I Solved Sample Papers
5. Engineering Mathematics 1 Solved Sample Papers.
6. Engineering Chemistry Solved Sample Papers.


MDU BE/B.Tech 2nd Semester Solved Sample Papers.  Previous Year MDU BE/B.Tech Solved Sample Papers.  Shortcut to prepare for your semester exams.
  1. Engineering Physics 2 Solved Sample Paper.
  2. Engineering Mathematics 2nd Solved Sample Paper.
  3. Communication Skills in English Solved Sample Paper.
  4. Elements Of Mechanical Engineering Solved Sample Paper.
  5. Electrical Technology Solved Sample Papers.
  6. Basics Of Electronics Solved Sample Papers.

www.CodeNirvana.in

www.posthatke.com. Powered by Blogger.
Copyright © www.posthatke.com | Blogger Templates | Designed By posthatke.com