logo

Question-Bank

  • Home
  • About_us
  • What is Software Engineering/Define sotware Engineering?
    "2-Mark"
    Software engineering is an engineering-based approach to software development. A software engineer is a person who applies the engineering design process to design, develop, maintain, test, and evaluate computer software.
  • Why Software is Expensive?
    "2-Mark"
    Every software development project is unique and demands a diverse set of skills, technologies and expertise. Because technology continues to rapidly evolve, it is critical to have a team that is on the leading edge and has a fundamental understanding of legacy systems.
  • Define Software Reliability?
    "2-Mark"
    software reliability can be defined as the probability of failure-free operation of a computer program in a specified environment for a specified time. This definition is straightforward, but, when the reliability is expressed in this way, it is hard to interpret.
  • How to define a problem?
    "2-Mark"
    Describe what the system will do & what the solution needs to achieve.
    The requirements of the system give direction to the project.
    Requirements are defined as features, properties and behaviours a system nust have to achieve its purpose.
  • Define SRS?/ What is Software requirement specification
    "2-mark"
    A software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.
    An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost.
    A good SRS defines how an application will interact with system hardware, other programs and human users in a wide variety of real-world situations
  • What is role of Problem analysis in software Engineering?
    Problem analysis therefore involves identifying the overriding problem and establishing the causes and effects related to that problem. A key element of this analysis will ensure that “root causes,” not just the symptoms of the problem, are identified and subsequently addressed in the project design.
  • What are the characteristic of SRS or Software Requirement Specification?
    "2-mark"
    To properly satisfy the basic goals an SRS should have certain properties and should contain different types of requirements. A good SRS document should have the following characteristics:
    1. Completeness
    2. Clarity
    3. Correctness
    4. Consistency
    5. Verifiability
    6. Ranking
    7. Modifiability
    8. Traceability
    9. Feasibility
    "5-mark"
    1. Completeness:
    A SRS is complete if everything the software the software is supposed to do and the responses of the software to all class of input data are specified in SRS. It ensures that everything is indeed specified. It is one of the most difficult properties to spot. To ensure completeness, one has to detect the absence of specification which is much harder to determine.
    2. Clarity:
    The documented requirement should lead to only a single interpretation, independent of the person or the time when the interpretation is done.
    3. Correctness:
    The SRS can be considered as correct if every requirements stated in the SRS is required in the proposed system.Ensures that what is specified is done correctly.
    4.Consistency:
    Requirements at all levels must be consistent with each other any conflict between requirements within the SRS must be identified and resolved.
    5. Verifiability:
    A SRS is verifiable if and only if every stated requirement is verifiability. A requirement is verifiable if there exists some cost effective process that can check whether the final software meets that requirements un ambiguity is essential for verifiability of requirements is often done through reviews it also implies that SRS in understandable, at least by the developer the client and the users.
    6. Ranking :
    Generally, the requirements are stated according to their priorities are critical, other are important but not critical, and there are some which are desirable but not very important. Similarly some requirements are core requirements which are not likely to change as time passes, while others are more dependent on time. A SRS is ranked for importance and or stability if for each requirement the importance and the stability of the requirements are indicated.
    7. Modificability:
    The SRS needs to be documented in such a manner that a history of changes can be contained in the document. It will also necessary to be able to highlight and tr5ace the changes of the requirements as we progress through the project.
    8. Tracability:
    As SRS is traceable if the origin of each its requirements is clear and if it facilitates the referencing of each requirements in future development.
    9. Feasibility:
    Though it may not be possible to confirm the feasibility of implementation of all the requirements any requirement which is apparent infeasible, should be eliminated from the SRS.
  • What is Software Maintenance?
    "2-mark"
    Software maintenance is the process of changing, modifying, and updating software to keep up with customer needs.
    Software maintenance is done after the product has launched for several reasons including improving the software overall, correcting issues or bugs, to boost performance, and more. "10-mark" / "5-mark"
    Software maintenance is the process of changing, modifying, and updating software to keep up with customer needs.
    Software maintenance is done after the product has launched for several reasons including improving the software overall, correcting issues or bugs, to boost performance, and more.
    Need for Maintenance
    Software Maintenance is needed for:-
    Correct errors
    Change in user requirement with time
    Changing hardware/software requirements
    To improve system efficiency
    To optimize the code to run faster
    To modify the components
    To reduce any unwanted side effects.
    Types of software maintanence 1. Corrective Maintenance
    Corrective maintenance aims to correct any remaining errors regardless of where they may cause specifications, design, coding, testing, and documentation, etc.
    2. Adaptive Maintenance
    It contains modifying the software to match changes in the ever-changing environment.
    3. Preventive Maintenance
    It is the process by which we prevent our system from being obsolete. It involves the concept of reengineering & reverse engineering in which an old system with old technology is re-engineered using new technology. This maintenance prevents the system from dying out.
    4. Perfective Maintenance
    It defines improving processing efficiency or performance or restricting the software to enhance changeability. This may contain enhancement of existing system functionality, improvement in computational efficiency, etc.
  • What is a Software Metrics?
    "2-mark"
    A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses.
    "5-mark"/"10-mark"
    A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses.
    Software metrics in software engineering should possess the following characteristics:
    Quantitative: Metrics must be quantitative in order to be helpful. It means that metrics can be stated numerically.
    Understandable: Metric computation should be simple to grasp, and the method for computing them should be well explained.
    Applicability: Metrics should be applied during the early stages of software development.
    Repeatable: When measured regularly and consistently in nature, the metric values should be the same.
    Economical: Metric computation should be cost-effective.
    Language agnostic: Metrics should be language-independent, meaning their computation should not depend on any programming language.
    Need for Software Metrics
     Software metrics in software engineering can be used for a variety of purposes, including analyzing software performance, planning work items, estimating productivity, and so on. For example, you can use software metrics to monitor performance, plan upcoming work tasks, track productivity, and better regulate the production process throughout project management if you can view distinct statistics and trends as production takes place
    Types of Metrics
     Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
    External metrics: External metrics are the metrics used for measuring properties that are viewed to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
    Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For example, cost per FP where FP stands for Function Point Metric.
    Project metrics: Project metrics are the metrics used by the project manager to check the project's progress. Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as a base of new software.
  • What are Software Cost Factors?
    The key factors that distinguish development and maintenance and which lead to higher maintenance cost are divided into two sub-categories.
    • Non-technical factors
    • Technical factors
    Non-Technical Factors
    The non-technical factors include:
    • Application domain
    • Staff stability
    • Program lifetime
    • Dependence on External Environment
    • Hardware stability
    Application domain
    • If the application of the program is clearly defined and well understood, the system requirements may be definitive and maintenance due to changing requirements to minimized.
    • If the application is completely new, it is likely that the initial requirements will be modified frequently, as users gain experience with the system.
    Staff stability
    • It is easier for the original writer of a program to understand and change a program rather than some other individual who must understood the program by study of its documentation and code listing.
    • If the programmer of a system also maintains that system, maintenance cost will be reduced.
    Program lifetime
    • The useful life of a program depend on its application.
    • Programs become obsolete when the application becomes obsolete or their original hardware is replaced and conversion costs exceed rewriting costs.
    Dependence on External Environment
    • If a program is dependent on its external environment, it must be modified as the environment change.
    • For example:
    - Changes in a taxation system might require payroll, accounting, and stock control programs to be modified.
    - Taxation changes are relatively common and maintenance costs for these programs are related tot eh frequency of these changes.
    Hardware stability
    • If a program is designed to operate on a particular hardware configuration and that configuration does not change during the program’s lifetime, no maintenance cost due to hardware changes will be incurred.
    • However, hardware developments are so rapid that this situation is rare.
    Technical Factors
    Technical factors include the following:
    • Module independence
    • Programming language
    • Programming style
    • Program validation and testing
    • Documentation
    • Configuration management techniques
    All the above technical factors are described below.
    Module Independence
    • It should be possible to modify one program unit of a system without affecting any other unit. Programming Language
    • Programs written in a high-level programming language are usually easier to understand (and hence maintain) than programs written in a low-level language.
    Programming Style
    • The way in which a program is written contributes to its understandability and hence the ease with which it can be modified.
    Program Validation and Testing
    • Generally, more the time and effort are spend on designing validation and program testing, the fewer errors in the program and, consequently, maintenance cost resulting from error correction are lower.
    • Maintenance costs due to error correction are governed by the type of error to be repaired.
    • Coding errors are usually relatively cheap to correct; design errors are more expensive as they may involve the rewriting of one or more program units.
    • Errors in the software requirements are usually the most expensive to correct because of the drastic redesign which is usually involved.
    Documentation
    • If a program is supported by clear, complete yet concise documentation, the task of understanding the program can be relatively straightforward.
    • Program maintenance costs tend to be less for well-documented systems than for systems supplied with poor or incomplete documentation. Configuration Management Techniques
    • One of the most significant costs of maintenance is keeping track of all system documents and ensuring that these are kept consistent.
    • Effective configuration management can help control this cost.
  • What are the challenges faced by software engineering?
    "5-mark"

    1. The rapid advancement of technology
    For the IT sector, every technological innovation is a blessing. The rapid advancement of technology puts additional pressure on software development professionals to take advantage of these trends when creating new software products to stand out from the crowd and obtain a competitive advantage. It is one of the major software engineering problems.
    2. Increasing customer demands in the development stage
    The majority of software projects are conceptual in nature and are focused on creating software solutions that satisfy a range of consumer needs. Even the simplest application or product requires developers to fully grasp the underlying business concept and incorporate the necessary functionality to meet the ever-increasing client needs. It is among the software engineer coding challenges faced in software development.
    3. Time limitation
    The deadlines set for software engineers are incredibly short and are one of the major challenges of being a software engineer. After all, it is a game of time. When engineers collaborate with several clients across various time zones, the process becomes considerably more difficult. These time restraints frequently cause development teams to work less productively, resulting in subpar-quality products.
    4. Limited infrastructure/ resources
    The lack of resources or IT infrastructure to carry out projects successfully is another issue that most software development companies deal with and is among the major problems of software engineering. It could be caused by a lack of high-performance programming tools, strong computing platforms, ineffective data storage structures, or bad networks and connections. These obstacles lower software engineers' productivity and effectiveness, which affects the end result.
    5. Understanding the large and complex system requirements is difficult
    We are all aware that engineers do not communicate with clients directly because clients are contacted through the project manager or bidder procedure. As a result, engineers face challenges when dealing with customers who have personal ideas about the software they want to use because they rarely have direct contact with them. It is one of the key challenges in software engineering.
  • Define Software development process models?
    "10-Mark"/"5-mark"
    A software process model is an abstraction of the software development process. The models specify the stages and order of a process. So, think of this as a representation of the order of activities of the process and the sequence in which they are performed. There are many kinds of process models for meeting different requirements. We refer to these as SDLC models (Software Development Life Cycle models).
    The most popular and important SDLC models are as follows:
    Waterfall Model
    The waterfall model is a sequential, plan driven-process where you must plan and schedule all your activities before starting the project. Each activity in the waterfall model is represented as a separate phase arranged in linear order.
    It has the following phases:
    Requirements
    Design
    Implementation
    Testing
    Deployment
    Maintenance
    Each of these phases produces one or more documents that need to be approved before the next phase begins. However, in practice, these phases are very likely to overlap and may feed information to one another.
    The waterfall model has a rigid structure, so it should be used in cases where the requirements are understood completely and unlikely to radically change. image Link:Click here
    V-Model
    The V model (Verification and Validation model) is an extension of the waterfall model. All the requirements are gathered at the start and cannot be changed. You have a corresponding testing activity for each stage. For every phase in the development cycle, there is an associated testing phase.
    The V model is highly disciplined, easy to understand, and makes project management easier. But it isn’t good for complex projects or projects that have unclear or changing requirements. This makes the V model a good choice for software where downtimes and failures are unacceptable. image link: Click here
    Increamental Model
    The incremental model divides the system’s functionality into small increments that are delivered one after the other in quick succession. The most important functionality is implemented in the initial increments.
    The subsequent increments expand on the previous ones until everything has been updated and implemented.
    Incremental development is based on developing an initial implementation, exposing it to user feedback, and evolving it through new versions. The process’ activities are interwoven by feedback.
    image link here:Click here
    Iterative Model
    The iterative development model develops a system by building small portions of all the features. This helps to meet the initial scope quickly and release it for feedback.
    In the iterative model, you start off by implementing a small set of software requirements. These are then enhanced iteratively in the evolving versions until the system is completed. This process model starts with part of the software, which is then implemented and reviewed to identify further requirements.
    Like the incremental model, the iterative model allows you to see the results at the early stages of development. This makes it easy to identify and fix any functional or design flaws. It also makes it easier to manage risk and change requirements.
    image link here:Click here
    Spiral Model
    The spiral model is a risk driven iterative software process model. The spiral model delivers projects in loops. Unlike other process models, its steps aren’t activities but phases for addressing whatever problem has the greatest risk of causing a failure.
    It was designed to include the best features from the waterfall and introduces risk-assessment.
    You have the following phases for each cycle:
    1.Address the highest-risk problem and determine the objective and alternate solutions.
    2.Evaluate the alternatives and identify the risks involved and possible solutions.
    3.Develop a solution and verify if it’s acceptable.
    4.Plan for the next cycle.
    image link here:Click here
  • Define Software testing and its types?
    Testing is the process of executing a program to find errors. To make our software perform well it should be error-free. If testing is done successfully it will remove all the errors from the software.
    Types of Testing:-
    1. Unit Testing
    Unit testing is a method of testing individual units or components of a software application. It is typically done by developers and is used to ensure that the individual units of the software are working as intended. Unit tests are usually automated and are designed to test specific parts of the code, such as a particular function or method. Unit testing is done at the lowest level of the software development process, where individual units of code are tested in isolation.
    2. Integration Testing
    Integration testing is a method of testing how different units or components of a software application interact with each other. It is used to identify and resolve any issues that may arise when different units of the software are combined. Integration testing is typically done after unit testing and before functional testing, and is used to verify that the different units of the software work together as intended.
    3. System Testing
    This software is tested such that it works fine for the different operating systems. It is covered under the black box testing technique. In this, we just focus on the required input and output without focusing on internal working. In this, we have security testing, recovery testing, stress testing, and performance testing
    4.Acceptance Testing
    Acceptance tests are formal tests that verify if a system satisfies business requirements. They require the entire application to be running while testing and focus on replicating user behaviors. But they can also go further and measure the performance of the system and reject changes if certain goals are not met.
    5.Smoke Testing
    Smoke tests are basic tests that check the basic functionality of an application. They are meant to be quick to execute, and their goal is to give you the assurance that the major features of your system are working as expected.
    Smoke tests can be useful right after a new build is made to decide whether or not you can run more expensive tests, or right after a deployment to make sure that they application is running properly in the newly deployed environment.
  • What is Black Box Testing?
    "5-mark"/"10-mark"
    Black box testing is a technique of software testing which examines the functionality of software without peering into its internal structure or coding. The primary source of black box testing is a specification of requirements that is stated by the customer.
    In this method, tester selects a function and gives input value to examine its functionality, and checks whether the function is giving expected output or not. If the function produces correct output, then it is passed in testing, otherwise failed. The test team reports the result to the development team and then tests the next function. After completing testing of all functions if there are severe problems, then it is given back to the development team for correction.
    Generic steps of black box testing
    The black box test is based on the specification of requirements, so it is examined in the beginning.
    In the second step, the tester creates a positive test scenario and an adverse test scenario by selecting valid and invalid input values to check that the software is processing them correctly or incorrectly.
    In the third step, the tester develops various test cases such as decision table, all pairs test, equivalent division, error estimation, cause-effect graph, etc.
    The fourth phase includes the execution of all test cases.
    In the fifth step, the tester compares the expected output against the actual output.
    In the sixth and final step, if there is any flaw in the software, then it is cured and tested again.
  • What is white Box testing?
    "5mark"/"10-mark"
    White box testing techniques analyze the internal structures the used data structures, internal design, code structure, and the working of the software rather than just the functionality as in black box testing. It is also called glass box testing or clear box testing or structural testing. White Box Testing is also known as transparent testing, open box testing.
    White box testing is a software testing technique that involves testing the internal structure and workings of a software application. The tester has access to the source code and uses this knowledge to design test cases that can verify the correctness of the software at the code level.
    White box testing is also known as structural testing or code-based testing, and it is used to test the software’s internal logic, flow, and structure. The tester creates test cases to examine the code paths and logic flows to ensure that they meet the specified requirements.
    Working process of white box testing:
    Input: Requirements, Functional specifications, design documents, source code.
    Processing: Performing risk analysis for guiding through the entire process.
    Proper test planning: Designing test cases so as to cover the entire code. Execute rinse-repeat until error-free software is reached. Also, the results are communicated.
    Output: Preparing final report of the entire testing process.
  • What is a Software architect?
    '2-mark'
    A software architect is responsible for planning and organizing a software system. These experts dictate coding standards and choose optimal tools for custom software development. They also help translate ideas into technical tasks and correctly distribute them to the development team.
    "10-mark"
    A software architect is responsible for planning and organizing a software system. These experts dictate coding standards and choose optimal tools for custom software development. They also help translate ideas into technical tasks and correctly distribute them to the development team.
    Duties of software architect:
    Pre-Development Stage:
    Primary responsibilities of a software architect at this stage include:
    ⚫Gathering early functional and non-functional requirements;
    ⚫Selecting a technology stack;
    ⚫Estimating development time;
    ⚫Delivering a high-level architectural design.
    Prototyping
    ⚫Address possible risks and constraints;
    ⚫Provide detailed architectural blueprints;
    ⚫Prove the solution’s viability.
    Development
    ⚫Setting quality standards;
    ⚫Change management;
    ⚫Development team mentoring;
    ⚫Further architecture specification;
    Quality Assurance
    ⚫Testing and deployment supervision;
    ⚫Releases management.
    Post-Development Stage
    ⚫Ensuring the product is functional;
    ⚫Communication with the client.
  • What is the role of software Architect?
    A Software Architect provides a solution that the technical team can create and design for the entire application. A software architect should have expertise in the following areas −
    Design Expertise
    Expert in software design, including diverse methods and approaches such as object-oriented design, event-driven design, etc.
    Lead the development team and coordinate the development efforts for the integrity of the design.
    Should be able to review design proposals and tradeoff among themselves.
    Domain Expertise
    Expert on the system being developed and plan for software evolution.
    Assist in the requirement investigation process, assuring completeness and consistency.
    Coordinate the definition of domain model for the system being developed.
    Technology Expertise
    Expert on available technologies that helps in the implementation of the system.
    Coordinate the selection of programming language, framework, platforms, databases, etc.
    Methodological Expertises
    Expert on software development methodologies that may be adopted during SDLC (Software Development Life Cycle).
    Choose the appropriate approaches for development that helps the entire team.
    Hidden Role of Software Architect
    Facilitates the technical work among team members and reinforcing the trust relationship in the team.
    Information specialist who shares knowledge and has vast experience.
    Protect the team members from external forces that would distract them and bring less value to the project.
  • What are the risk Management technique?
    "2-Mark" A risk is a probable problem- it might happen or it might not. There are main two characteristics of risk
    Uncertainty- the risk may or may not happen that means there are no 100% risks. loss-If the risk occurs in reality , undesirable result or losses will occur.
    Risk management is a sequence of steps that help a software team to understand , analyze and manage uncertainty. Risk management consists of
    Risk Identification
    Risk analysis
    Risk Avoidance
    Risk Monitoring
    "5-mark"
    Risk Identification
    Risk identification involves brainstorming activities. it also involves the preparation of a risk list. Brainstorming is a group discussion technique where all the stakeholders meet together. this technique produces new ideas and promotes creative thinking.
    Risk analysis
    It is a process that consists of the following steps:
    Identifying the problems causing risk in projects
    Identifying the probability of occurrence of problem
    Identifying the impact of problem
    Assigning values to step 2 and step 3 in the range of 1 to 10
    Calculate the risk exposure factor which is the product of values of step 2 and step 3
    Prepare a table consisting of all the values and order risk on the basis of risk exposure factor
    Risk Avoidance
    The purpose of this technique is to altogether eliminate the occurrence of risks. so the method to avoid risks is to reduce the scope of projects by removing non-essential requirements.
    Risk Monitoring
    In this technique, the risk is monitored continuously by reevaluating the risks, the impact of risk, and the probability of occurrence of the risk.
    This ensures that:
    Risk has been reduced
    New risks are discovered
    Impact and magnitude of risk are measured
  • What is C and C or components and connectors
    "2-Mark"
    Compenent
    Component is a unit of behavior. Its description defines what the component can do and what it requires to do that job.
    Connectors
    Connector is an indication that there is a mechanism that relates one component to another usually through relationships such as data flow or control flow.
  • Define UMl
    "2-mark"
    The UML stands for Unified modeling language, is a standardized general-purpose visual modeling language in the field of Software Engineering. It is used for specifying, visualizing, constructing, and documenting the primary artifacts of the software system. It helps in designing and characterizing, especially those software systems that incorporate the concept of Object orientation. It describes the working of both the software and hardware systems.
  • How to write a good SRS?
    You can think of an SRS as a blueprint or roadmap for the software you're going to build. The elements that comprise an SRS can be simply summarized into four Ds:
    Define your product's purpose.
    Describe what you're building.
    Detail the requirements.
    Deliver it for approval.
  • What is Software design?
    "2-Mark"
    Software design is a mechanism to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. It deals with representing the client's requirement, as described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable using programming language.
    "5-mark"
    Software design is a mechanism to transform user requirements into some suitable form, which helps the programmer in software coding and implementation. It deals with representing the client's requirement, as described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable using programming language.
    Correctness:Software design should be correct as per requirement.
    Completeness:The design should have all components like data structures, modules, and external interfaces, etc.
    Efficiency:Resources should be used efficiently by the program.
    Flexibility:Able to modify on changing needs.
    Consistency:There should not be any inconsistency in the design.
    Maintainability: The design should be so simple so that it can be easily maintainable by other designers.
  • Define Coupling and cohension?
    Coupling
    '2-Mark'
    Coupling refers to the degree of interdependence between software modules. High coupling means that modules are closely connected and changes in one module may affect other modules. Low coupling means that modules are independent and changes in one module have little impact on other modules.
    "5-mark"
    Coupling is the measure of the degree of interdependence between the modules. A good software will have low coupling.
    Types of Coupling:
    Data Coupling:
    If the dependency between the modules is based on the fact that they communicate by passing only data, then the modules are said to be data coupled. In data coupling, the components are independent of each other and communicate through data. Module communications don’t contain tramp data. Example-customer billing system.
    Stamp Coupling:
    In stamp coupling, the complete data structure is passed from one module to another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice was made by the insightful designer, not a lazy programmer.
    Control Coupling:
    If the modules communicate by passing control information, then they are said to be control coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and reuse of functionality. Example- sort function that takes comparison function as an argument.
    External Coupling:
    In external coupling, the modules depend on other modules, external to the software being developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.
    Common Coupling:
    The modules have shared data such as global data structures. The changes in global data mean tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to control data accesses, and reduced maintainability.
    Cohension
    "2-mark"
    Cohesion refers to the degree to which elements within a module work together to fulfill a single, well-defined purpose. High cohesion means that elements are closely related and focused on a single purpose, while low cohesion means that elements are loosely related and serve multiple purposes.
    "5-mark"
    Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the degree to which all elements directed towards performing a single task are contained in the component. Basically, cohesion is the internal glue that keeps the module together. A good software design will have high cohesion.
    Types of cohension
    Functional Cohesion:
    Every essential element for a single computation is contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.
    Sequential Cohesion:
    An element outputs some data that becomes the input for other element, i.e., data flow between the parts. It occurs naturally in functional programming languages.
    Communicational Cohesion:
    Two elements operate on the same input data or contribute towards the same output data. Example- update record in the database and send it to the printer.
    Procedural Cohesion:
    Elements of procedural cohesion ensure the order of execution. Actions are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA, print cumulative GPA.
    Temporal Cohesion:
    The elements are related by their timing involved. A module connected with temporal cohesion all the tasks must be executed in the same time span. This cohesion contains the code for initializing all the parts of the system. Lots of different activities occur, all at unit time.
    Logical Cohesion:
    The elements are logically related and not functionally. Ex- A component reads inputs from tape, disk, and network. All the code for these functions is in the same component. Operations are related, but the functions are significantly different.
    Coincidental Cohesion:
    The elements are not related(unrelated). The elements have no conceptual relationship other than location in source code
  • What is DFD or Data flow Diagram?
    A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system. A neat and clear DFD can depict the right amount of the system requirement graphically. It can be manual, automated, or a combination of both. Some essential things
    All names should be unique. This makes it easier to refer to elements in the DFD.
    Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of events; arrows in DFD represents flowing data. A DFD does not involve any order of events.
    Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents decision points with multiple exists paths of which the only one is taken. This implies an ordering of events, which makes no sense in a DFD.
    Do not become bogged down with details. Defer error conditions and error handling until the end of the analysis
    Standard Symbols in Dfd
    Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.
    Data Flow: A curved line shows the flow of data into or out of a process or data store.
    Data Store: A set of parallel lines shows a place for the collection of data items. A data store indicates that the data is stored which can be used at a later stage or by the other processes in a different order. The data store can have an element or group of elements.
    Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of system outputs.
  • What is Data dictionary?
    Data Dictionary is the major component in the structured analysis model of the system. It lists all the data items appearing in DFD. A data dictionary in Software Engineering means a file or a set of files that includes a database’s metadata (hold records about other objects in the database), like data ownership, relationships of the data to another object, and some other data.
    Components of Data dictionary
    Name of the item: It can be your choice.
    Aliases: It represents another name.
    Description: Description of what the actual text is all about.
    Related data items: with other data items.
    Range of values: It will represent all possible answers.
    Notation of Data Dictionary X = a+b X consists data elements a and b.
    X = [a/b] X consists of either elements a or b.
    X = a X X consists of optimal data elements a.
    X = y[a] X consists of y or more events of data element a
    X = [a] z X consists of z or less events of data element a
    X = y [a] z X consists of some events of data elements between y and z.
  • Object Oriented concept in Software Engineering?
    In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The state is distributed among the objects, and each object handles its state data. For example, in a Library Automation Software, each library representative may be a separate object with its data and functions to operate on these data.
    Different Terms related to Object Oriented
    Objects:
    All entities involved in the solution design are known as objects. For example, person, banks, company, and users are considered as objects. Every entity has some attributes associated with it and has some methods to perform on the attributes.
    Classes:
    A class is a generalized description of an object. An object is an instance of a class. A class defines all the attributes, which an object can have and methods, which represents the functionality of the object.
    Messages:
    Objects communicate by message passing. Messages consist of the integrity of the target object, the name of the requested operation, and any other action needed to perform the function. Messages are often implemented as procedure or function calls.
    Abstraction:
    In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of the irrelevant and the amplification of the essentials.
    Encapsulation:
    Encapsulation is also called an information hiding concept. The data and operations are linked to a single unit. Encapsulation not only bundles essential information of an object together but also restricts access to the data and methods from the outside world.
    Inheritance:
    OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes can import, implement, and re-use allowed variables and functions from their immediate superclasses.This property of OOD is called an inheritance. This makes it easier to define a specific class and to create generalized classes from specific ones.
    Polymorphism:
    OOD languages provide a mechanism where methods performing similar tasks but vary in arguments, can be assigned the same name. This is known as polymorphism, which allows a single interface is performing functions for different types. Depending upon how the service is invoked, the respective portion of the code gets executed.
  • What is Project Sheduling?
    Project-task scheduling is a significant project planning activity. It comprises deciding which functions would be taken up when. To schedule the project plan, a software project manager wants to do the following:
    Identify all the functions required to complete the project.
    Break down large functions into small activities.
    Determine the dependency among various activities.
    Establish the most likely size for the time duration required to complete the activities.
    Allocate resources to activities.
    Plan the beginning and ending dates for different activities.
    Determine the critical path. A critical way is the group of activities that decide the duration of the project.
  • What is project Planning?
    The project planning phase refers to:
    Developing a project to make it ready for investment
    Determines the jobs/tasks required to attain project objectives
    The project planning stages are enlisted below:
    Identifying the key project sponsors and stakeholders, to determine the basis of project scope, budget, and time-frame for project execution.
    Upon enlisting the stake-holder requirements, prioritizing/setting project objectives.
    Identifying the project deliverables required to attain the project objectives.
    Creating the project schedule.
    Identifying the project risks, if any, and develop suitable mitigation plans.
    Communicating and presenting the project plan to stakeholders.
  • What is COCOMO model?
    "2-mark"
    COCOMO is based upon the estimation of lines of code in a system and the time.COCOMO has also considered the aspects like project attributes, hardware, assessment of produce, etc. This provides transparency to the model which allows software managers to understand why the model gives the estimates it does.
    "5-mark"/"10-Mark"
    Software projects under COCOMO model strategies are classified into 3 categories, organic, semi-detached, and embedded.
    Organic:
    A software project is said to be an organic type if-
    Project is small and simple.
    Project team is small with prior experience.
    The problem is well understood and has been solved in the past.
    Requirements of projects are not rigid, such a mode example is payroll processing system.
    Semi-Detached Mode:
    A software project is said to be a Semi-Detached type if-
    Project has complexity.
    Project team requires more experience,better guidance and creativity.
    The project has an intermediate size and has mixed rigid requirements such a mode example is a transaction processing system which has fixed requirements.
    It also includes the elements of organic mode and embedded mode.
    Few such projects are- Database Management System(DBMS), new unknown operating system, difficult inventory management system.
    Embedded Mode
    A software project is said to be an Embedded mode type if-
    A software project has fixed requirements of resources .
    Product is developed within very tight constraints.
    A software project requiring the highest level of complexity, creativity, and experience requirement fall under this category.
    Such mode software requires a larger team size than the other two models.
    Types of Cocomo Model COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. Any of the three forms can be adapted according to our requirements. These are types of COCOMO model:
    Basic COCOMO Model
    Intermediate COCOMO Model
    Detailed COCOMO Model