image

Solution of Assignment Synopsis & Project Dissertation Report


PRODUCT DETAILS

Online-Typing-and-Filling

Title Name Amity Solved Assignment BSC IT 5th Sem for Software Engineering
University AMITY
Service Type Assignment
Course B.Sc-(IT)
Semister Semester-V Cource: B.Sc-(IT)
Short Name or Subject Code SOFTWARE ENGINEERING
Commerce line item Type Semester-V Cource: B.Sc-(IT)
Product Assignment of B.Sc-(IT) Semester-V (AMITY)

Solved Assignment


  Questions :-

                                                                                                                      Software Engineering 

Assignment A

Note: Question is not may be serial, Kindly find & search.

 

1 .

Explain the Spiral Model of software development. What are the limitations of    such a model?  

 

2 .

Is it possible to estimate software size before coding? Justify your answer with suitable examples

 

3 .

Explain the concepts of Function Points. Why FPs is becoming acceptable in industry?     

 

4 .

The effort distribution for a 420 KLOC Semi-detached mode software development project is: product design 10%, detailed design 14%, code & unit test 26%, integrate and test 30%. How would the following change, from low to high, affect the phase distribution of effort and the total effort: analyst Capability, virtual machine experience, Programmer capability, and required language experience?

 

5 .

What do you understand by the term Software Development Life Cycle? Why is it important to adhere to a life cycle model while developing a large software system? 

 

6 .

List the five desirable characteristics of good SRS document

 

7 .

Enumerate the different types of coupling that might exist between two modules.

 

 Assignment B

  1. Consider a project to develop a full screen editor. The major components identified are (1) screen editor (2) command language interpreter (3) file input output, (4) cursor movement and (5) screen movement. The sizes for these are estimated to be 4K, 2K, 1K, 2K and 3K delivered source code lines. Use COCOMO model to determine: (i) Overall cost and schedule estimates (assume values for different cost drivers, with at least three being different from 1.0) (ii) Cost and schedule estimates for different phases.

Q2 - Explain why a design with low coupling helps maintainability

  1. Discuss the significance and use of requirement engineering. What are the problems in the formulation of requirements?

 

 

Assignment C

Question No.  1          Marks - 10

________________________________________

The development is supposed is supposed to be processed linearly through the phases

Options                      

  1. Spiral Model
  2. Waterfall Model
  3. Prototyping Model
  4. None of the above

 

 

Question No.  2          Marks - 10

________________________________________

The DFD depicts                                          

Options                      

  1. Flow of data
  2. Flow of control
  3. Both A & B
  4. None of the above

 

 

Question No.  3          Marks - 10

________________________________________

The most desirable form of coupling is                  

Options                      

  1. Control Coupling
  2. Common Coupling
  3. Data Coupling
  4. Content Coupling

 

 

Question No.  4          Marks - 10

________________________________________

If failure intensity is 0,005 failures/hour during 10 hours of operation of software, its reliability can be expressed as  

Options          

  1. 90
  2. 92
  3. 95
  4. 98

 

 

Question No.  5          Marks - 10

________________________________________

Regression testing is primarily related to               

Options          

  1. Functional Testing
  2. Data Flow Testing
  3. Development Testing
  4. Maintenance Testing

 

 

Question No.  6          Marks - 10

________________________________________

Which one is not a step of requirement engineering?       

Options                      

  1. Requirement Elicitation
  2. Requirement Analysis
  3. Requirement Design
  4. Requirement Documentation

 

 

Question No.  7          Marks - 10

________________________________________

Which one is not a requirement elicitation technique?     

Options          

  1. Interviews
  2. The use case approach
  3. FAST
  4. Data flow diagram

 

 

Question No.  8          Marks - 10

________________________________________

Level-O DFD is similar to    

Options                      

  1. Use case diagram
  2. Context diagram
  3. System diagram
  4. None of the above

 

 

Question No.  9          Marks – 10

________________________________________

The DFD depicts      

Options                      

  1. Flow of data
  2. Flow of control
  3. Both (a) & (b)
  4. None of the above

 

 

Question No.  10        Marks - 10

________________________________________

Which one is not a size measure for software?      

Options          

  1. LOC
  2. Function Point
  3. Cyclamate Complexity
  4. Halstead’s Program Length

 

 

Question No.  11        Marks - 10

________________________________________

Estimation of size for a project dependent on       

Options                      

  1. Cost
  2. Schedule
  3. Time
  4. None of the above

 

 

Question No.  12        Marks - 10

________________________________________

COCOMO-II was developed at      

Options                      

  1. University of Maryland
  2. University of Southern California
  3. IBM
  4. At & T Bell Labs

 

 

Question No.  13        Marks - 10

________________________________________

How many stages are in COCOMO-II?     

Options                      

  1. 2
  2. 3
  3. 4
  4. 5

 

 

Question No.  14        Marks - 10

________________________________________

Which one is not a risk Management Activity?     

Options                      

  1. Risk Assessment
  2. Risk control
  3. Risk Generation
  4. None of the above

 

 

Question No.  15        Marks – 10

________________________________________

The worst type of cohesion is          

Options                      

  1. Temporal Cohesion
  2. Coincidental Cohesion
  3. Logical Cohesion
  4. Sequential Cohesion

 

 

Question No.  16        Marks - 10

________________________________________

. Which one is not a strategy for design?   

Options                      

  1. Bottom up design
  2. Top Down design
  3. Embedded design
  4. Hybrid design

 

 

Question No.  17        Marks - 10

________________________________________

A system that does not interact with external environment is called       

Options                      

  1. Closed System
  2. Logical System
  3. Open System
  4. Hierarchal System

 

 

Question No.  18        Marks - 10

________________________________________

The extent to which different modules are dependent upon each other is called           

Options          

  1. Coupling
  2. Cohesion
  3. Modularity
  4. Stability

 

 

Question No.  19        Marks - 10

________________________________________

Which one is not a category of software metrics? 

Options                      

  1. Product metrics
  2. Process metrics
  3. Project metrics
  4. People metrics

 

 

Question No.  20        Marks - 10

________________________________________

 

Which one is not a measure of software science theory?  

Options                      

  1. Vocabulary
  2. Volume
  3. Level
  4. Logic

 

 

Question No.  21        Marks - 10

________________________________________

Minimal implementation of any algorithm was given the following name by Hallstead:          

Options          

  1. Volume
  2. Potential Volume
  3. Effective Volume
  4. None of the above

 

 

Question No.  22        Marks - 10

________________________________________

 

Which one is the International standard for size measure?         

Options                      

  1. LOC
  2. Function Point
  3. Program Length
  4. None of the above

 

 

Question No.  23        Marks - 10

________________________________________

. Fault is         

Options          

  1. Defect in the program
  2. Mistake in the program
  3. Error in the program
  4. All of the above

 

 

Question No.  24        Marks - 10

________________________________________

As the reliability increases, failure intensity           

Options                      

  1. Decreases
  2. Increases
  3. No effect
  4. None of the above

 

 

Question No.  25        Marks - 10

________________________________________

Software Quality is   

Options                      

  1. Conformance to requirements
  2. Fitness for the purpose
  3. Level of satisfaction
  4. All of the above

 

 

Question No.  26        Marks - 10

________________________________________

How many product quality factors have been proposed in McCall quality model?      

Options                      

  1. 2
  2. 11
  3. 3
  4. 6

 

 

Question No.  27        Marks - 10

________________________________________

 

Which one is not a software quality model?          

Options                      

  1. McCall Model
  2. Boehm Model
  3. ISO9000
  4. ISO9126

 

 

Question No.  28        Marks - 10

________________________________________

NHPP stands for      

Options          

  1. Non Homogeneous Poisson Process
  2. Non Heterogeneous Poisson Process
  3. Non Homogeneous Poisson Product
  4. Non Heterogeneous Poisson Product

 

 

Question No.  29        Marks - 10

________________________________________

Total numbers of maturing levels in CMM are     

Options                      

  1. 1
  2. 5
  3. 3
  4. 7

 

 

Question No.  30        Marks - 10

________________________________________

CMM is developed by          

Options                      

  1. Harvard University
  2. Cambridge University
  3. Carnegie Mellon University
  4. Maryland University

 

 

Question No.  31        Marks - 10

________________________________________

Software reliability is defined with respect to        

Options                     

  1. Time
  2. Speed
  3. Quality
  4. None of the above

 

 

Question No.  32        Marks - 10

________________________________________

Software mistakes during coding are known as:  

Options                      

  1. Failures
  2. Defects
  3. Bugs
  4. Errors

 

 

Question No.  33        Marks - 10

________________________________________

For a function of two variables, how many test cases robustness testing will generate?           

Options                      

  1. 9
  2. 13
  3. 25
  4. 42

 

 

Question No.  34        Marks - 10

________________________________________

Beta testing is carried out by:          

Options          

  1. Users
  2. Developers
  3. Testers
  4. All of the above

 

 

Question No.  35        Marks - 10

________________________________________

Acceptance testing is done by:        

Options          

  1. Set of test cases
  2. Set of inputs
  3. Set of Outputs
  4. None of the above

 

 

Question No.  36        Marks - 10

________________________________________

Cyclomatic Complexity is equal to  

Options          

  1. Number of independent paths
  2. Number of paths
  3. Number of edges
  4. None of the above

 

 

Question No.  37        Marks - 10

________________________________________

Alpha & Beta testing techniques are related to     

Options                      

  1. System Testing
  2. Unit Testing
  3. Acceptance Testing
  4. Integration Testing

 

 

Question No.  38        Marks - 10

________________________________________

Integration testing techniques are   

Options          

  1. Top down
  2. Bottom up
  3. Sandwich
  4. All of the above

 

 

Question No.  39        Marks - 10

________________________________________

Functionality of software is tested by         

Options                      

  1. White box testing
  2. Black box testing
  3. Regression testing
  4. None of the above

 

 

Question No.  40        Marks - 10

________________________________________

Thread testing is used for testing    

Options                      

  • Real time systems
  • Object oriented systems
  • Event driven systems
  • All of the above
  Answers :-

 

                                                                                                           Software Engineering Assignment A

 

1 .Explain the Spiral Model of software development. What are the limitations of    such a model?   

Answer:

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals.

  • Identification: This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase.

This also includes understanding the system requirements by continuous communication between the customer and the system analyst. At the end of the spiral the product is deployed in the identified market.

  • Design: Design phase starts with the conceptual design in the baseline spiral and involves architectural design, logical design of modules, physical product design and final design in the subsequent spirals.
  • Construct or Build: Construct phase refers to production of the actual software product at every spiral. In the baseline spiral when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback.

Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called build is produced with a version number. These builds are sent to customer for feedback.

  • Evaluation and Risk Analysis: Risk Analysis includes identifying, estimating, and monitoring technical feasibility and management risks, such as schedule slippage and cost overrun. After testing the build, at the end of first iteration, the customer evaluates the software and provides feedback.

Following is a diagrammatic representation of spiral model listing the activities in each phase:

Based on the customer evaluation, software development process enters into the next iteration and subsequently follows the linear approach to implement the feedback suggested by the customer. The process of iterations along the spiral continues throughout the life of the software.

Spiral Model Application

Spiral Model is very widely used in the software industry as it is in synch with the natural development process of any product i.e. learning with maturity and also involves minimum risk for the customer as well as the development firms. Following are the typical uses of Spiral model:

  • When costs there is a budget constraint and risk evaluation is important.
  • For medium to high-risk projects.
  • Long-term project commitment because of potential changes to economic priorities as the requirements change with time.
  • Customer is not sure of their requirements which is usually the case.
  • Requirements are complex and need evaluation to get clarity.
  • New product line which should be released in phases to get enough customer feedback.
  • Significant changes are expected in the product during the development cycle.

Spiral Model Pros and Cons

The advantage of spiral lifecycle model is that it allows for elements of the product to be added in when they become available or known. This assures that there is no conflict with previous requirements and design.

This method is consistent with approaches that have multiple software builds and releases and allows for making an orderly transition to a maintenance activity. Another positive aspect is that the spiral model forces early user involvement in the system development effort.

On the other side, it takes very strict management to complete such products and there is a risk of running the spiral in indefinite loop. So the discipline of change and the extent of taking change requests is very important to develop and deploy the product successfully.

 

Disadvantages of Spiral model:

Can be a costly model to use.

Risk analysis requires highly specific expertise.

Project’s success is highly dependent on the risk analysis phase.

Doesn’t work well for smaller projects.

 

 

2 .Is it possible to estimate software size before coding? Justify your answer with suitable examples 

Answer:

You can estimate the size of a project in any of several ways:

  • Use an algorithmic approach such as function points that estimates program size from program features.
  • Use size estimation software.
  • If you have already worked on a similar project and know its size, estimate each major piece of the new system as a percentage of the size of a similar piece of the old system. Estimate the total size of the new system by adding up the estimated sizes of each of the pieces.


We will see another approach than line-code sizing: 


Fonction-Point Estimation:
Function Point Analysis was developed first by Allan J. Albrecht in the mid-1970s. It was an attempt to overcome difficulties associated with lines of code as a measure of software size, and to assist in developing a mechanism to predict effort associated with software development. The method was first published in 1979, then later in 1983. In 1984 Albrecht refined the method and since 1986, when the International Function Point User Group (IFPUG) was set up, several versions of the Function Point Counting Practices Manual have been published by IFPUG. The current version of the IFPUG Manual is 4.1. 


The number of function points in a program is based on the number and complexity of each of the following items:

  1. External Inputs (EI)- is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files. The data can be either control information or business information. If the data is control information it does not have to update an internal logical file. Screens, forms, boxes, controls, or messages through wich an end-user or other program ads, deletes or changes a program´s data. This includes any input that has a unique format or unique processing logic. 
  2. External Outputs (EO) - an elementary process in which derived datapasses across the boundary from inside to outside. Additionally, an EO may update an ILF. The data creates reports or output files sent to other applications. These reports and files are created from one or more internal logical files and external interface file. Screens, reports, graphs, or messages that the program generates for use by an end-user or other program. This includes any output that has a different format or requires a different processing logic than other output types. 
  3. External Inquiry (EQ) - an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files. The input process does not update any Internal Logical Files, and the output side does not contain derived data. Input/output combionations in which an input results in an immediat, simple output. The term originated in the database world and refer to a direct search for specific dat, usually using a single key. In modern GUI applications, the line between inquiries and output is blurry, generally, however, queries retrieve data directly from a database and only provide rudimentary formatting, whereas outputs can process, combine, or summarize complex data and can be highly formatted. 
  4. Internal Logical Files (ILF’s) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through external inputs. Major logical groups of end-user data or control information that are completely controlled by the program. A logical file might consist of a single flat file or a single table in a relational database. 
  5. External Interface Files (EIF’s) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The external interface file is an internal logical file for another application. Files Controlled by other programs with wich the program being counted interacts. This includes each major logical group of data or control information that enters or leaves the program.

Yes, you could base your estimate on experiences from the past. Mostly you´ll have coded likely features in other software and therefore you´ll have somewhat an idea how long it might take to program something similar.

 

 

3 .Explain the concepts of Function Points. Why FPs is becoming acceptable in industry?    

Answer:

To overcome these difficulties and to give a standardized view to the software a unit of software was derived know as Function Point.

The wikipedia defines function point as follows:

A Function Point is a unit of measurement to express the amount of business functionality an information system provides to a user.

To understand it better I would say that function point is to software as Celsius is to Temperature or KG is to weight or Meter is to length. It is simply a Unit of Measure for software.

Function points are an ISO recognized Software Metric to size an information system based on the functionality that is perceived by the user of the information system, independent of the technology used to implement the information system.

In summary, the function point technique provides an objective, comparative measure that assists in the evaluation, planning, management and control of software production.

This means that the size of the software can be measured in terms of function points. Now this is great as this will also allow us to come on the ground that we can charge a buyer of buy software based on the function points and there can be price fixed for each function point.

The concept of Function Point was originally defined by Allan Albrecht of IBM in 1977.

With FP (Function Point) came a standard methodology of determining the FP know as FPA (Function Point Analysis)

Function Point Analysis (FPA) is a sizing measure of clear business significance. First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within software in terms that are meaningful to the software users. The measure relates directly to the business requirements that the software is intended to address. It can therefore be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use. Other business measures, such as the productivity of the development process and the cost per unit to support the software, can also be readily derived.

The function point measure itself is derived in a number of stages. Using a standardized set of basic criteria, each of the business functions is a numeric index according to its type and complexity. These indices are totaled to give an initial measure of size which is then normalized by incorporating a number of factors relating to the software as a whole. The end result is a single number called the Function Point index which measures the size and complexity of the software product.

In summary, the function point technique provides an objective, comparative measure that assists in the evaluation, planning, management and control of software production.

Its worth mentioning that IFPUG (International Function Point User Group) is the architect and torch bearer for promoting the FPA methodology and effective management of Software Applications Development and maintenance through use of FPA.

 

 

4 .The effort distribution for a 420 KLOC Semi-detached mode software development project is: product design 10%, detailed design 14%, code & unit test 26%, integrate and test 30%. How would the following change, from low to high, affect the phase distribution of effort and the total effort: analyst Capability, virtual machine experience, Programmer capability, and required language experience?       

Answer:

Analyst capability

1.46

1.19

1.00

0.86

0.71

 

Applications experience

1.29

1.13

1.00

0.91

0.82

 

Software engineer capability

1.42

1.17

1.00

0.86

0.70

 

Virtual machine experience

1.21

1.10

1.00

0.90

   

Programming language experience

1.14

1.07

1.00

0.95

   

 

 

5 .What do you understand by the term Software Development Life Cycle? Why is it important to adhere to a life cycle model while developing a large software system?          

Answer:

SDLC, Software Development Life Cycle is a process used by software industry to design, develop and test high quality software’s. The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

SDLC is the acronym of Software Development Life Cycle.

It is also called as Software development process.

The software development life cycle (SDLC) is a framework defining tasks performed at each step in the software development process.

ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.

 

What is SDLC?

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

The following figure is a graphical representation of the various stages of a typical SDLC.

 

Stages of SDLC

A typical Software Development life cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis

Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational, and technical areas.

Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.

Stage 2: Defining Requirements

Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through .SRS. . Software Requirement Specification document which consists of all the product requirements to be designed and developed during the project life cycle.

Stage 3: Designing the product architecture

SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design approach for the product architecture is proposed and documented in a DDS - Design Document Specification.

This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity , budget and time constraints , the best design approach is selected for the product.

A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.

Stage 4: Building or Developing the Product

In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.

Developers have to follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers etc. are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.

Stage 5: Testing the Product

This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However this stage refers to the testing only stage of the product where products defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.

Stage 6: Deployment in the Market and Maintenance

Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometime product deployment happens in stages as per the organizations. business strategy. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing).

Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base.

SDLC Models

There are various software development life cycle models defined and designed which are followed during software development process. These models are also referred as "Software Development Process Models". Each process model follows a Series of steps unique to its type, in order to ensure success in process of software development.

Following are the most important and popular SDLC models followed in the industry:

  • Waterfall Model
  • Iterative Model
  • Spiral Model
  • V-Model
  • Big Bang Model

The other related methodologies are Agile Model, RAD Model, Rapid Application Development and Prototyping Models.

The Systems Development Life Cycle (SDLC) phases serve as a programmatic guide to project activity and provide a flexible but consistent way to conduct projects to a depth matching the scope of the project. Each of the SDLC phase objectives are described in this section with key deliverables, a description of recommended tasks, and a summary of related control objectives for effective management. It is critical for the project manager to establish and monitor control objectives during each SDLC phase while executing projects. Control objectives help to provide a clear statement of the desired result or purpose and should be used throughout the entire SDLC process. Control objectives can be grouped into major categories (Domains), and relate to the SDLC phases as shown in the figure

To manage and control any SDLC initiative, each project will be required to establish some degree of a Work Breakdown Structure (WBS) to capture and schedule the work necessary to complete the project. The WBS and all programmatic material should be kept in the “Project Description” section of the project notebook. The WBS format is mostly left to the project manager to establish in a way that best describes the project work. There are some key areas that must be defined in the WBS as part of the SDLC policy. The following diagram describes three key areas that will be addressed in the WBS in a manner established by the project manager.

 

 

6 .List the five desirable characteristics of good SRS document

Answer:

  1. Complete

A complete requirements specification must precisely define all the real world situations that will be encountered and the capability’s responses to them. It must not include situations that will not be encountered or unnecessary capability features.

  1. Consistent

System functions and performance level must be compatible and the required quality features (reliability, safety, security, etc.) must not contradict the utility of the system. For example, the only aircraft that is totally safe is one that cannot be started, contains no fuel or other liquids, and is securely tied down.

  1. Correct

The specification must define the desired capability’s real world operational environment, its interface to that environment and its interaction with that environment. It is the real world aspect of requirements that is the major source of difficulty in achieving specification correctness. The real world environment is not well known for new applications and for mature applications the real world keeps changing. The Y2K problem with the transition from the year 1999 to the year 2000 is an example of the real world moving beyond an application’s specified requirements.

  1. Modifiable

Related concerns must be grouped together and unrelated concerns must be separated. Requirements document must have a logical structure to be modifiable.

  1. Ranked

Ranking specification statements according to stability and/or importance is established in the requirements document’s organization and structure. The larger and more complex the problem addressed by the requirements specification, the more difficult the task is to design a document that aids rather than inhibits understanding.     

 

 

7 .Enumerate the different types of coupling that might exist between two modules.

Answer: solved by www.solvezone.in

Types of Coupling

Coupling can be "low" (also "loose" and "weak") or "high" (also "tight" and "strong"). Some types of coupling, in order of highest to lowest coupling, are as follows:

Content coupling (high)

Content coupling is when one module modifies or relies on the internal workings of another module (e.g., accessing local data of another module). Therefore changing the way the second module produces data (location, type, and timing) will lead to changing the dependent module.

Common coupling

Common coupling is when two modules share the same global data (e.g., a global variable). Changing the shared resource implies changing all the modules using it.

External coupling

External coupling occurs when two modules share an externally imposed data format, communication protocol, or device interface.

Control coupling

Control coupling is one module controlling the flow of another, by passing it information on what to do (e.g., passing a what-to-do flag). Stamp coupling (Data-structured coupling). Stamp coupling is when modules share a composite data structure and use only a part of it, possibly a different part (e.g., passing a whole record to a function that only needs one field of it). This may lead to changing the way a module reads a record because a field, which the module doesn´t need, has been modified.

Data coupling

Data coupling is when modules share data through, for example, parameters. Each datum is an elementary piece, and these are the only data shared (e.g., passing an integer to a function that computes a square root).

Message coupling (low)

This is the loosest type of coupling. It can be achieved by state decentralization (as in objects) and component communication is done via parameters or message passing. (See Message passing).

No coupling

Modules do not communicate at all with one another.

Conceptual model of coupling

 

 

 Assignment B

Consider a project to develop a full screen editor. The major components identified are (1) screen editor (2) command language interpreter (3) file input output, (4) cursor movement and (5) screen movement. The sizes for these are estimated to be 4K, 2K, 1K, 2K and 3K delivered source code lines. Use COCOMO model to determine: (i) Overall cost and schedule estimates (assume values for different cost drivers, with at least three being different from 1.0) (ii) Cost and schedule estimates for different phases.

Answer:

Size of five modules are:

Screen edit= 4 KLOC

Command language interpreter= 2 KLOC

File input and output = 1KLOC

Cursor movement = 2 KLOC

Screen movement = 3 KLOC

Total = 12 KLOC

 

Let us assume that significant cost drivers are

  1. Required software reliability is high, i.e. 1.15
  2. Product complexity is high i.e. 1.15
  3. Analyst capability is high, i.e. 0.86
  4. Programming language experience is low, i.e. 1.07
  5. All other drivers are nominal
  6. EAF = 1.15*1.15*0.86*1.07

= 1.2169

 

  • The initial effort estimate for the project is obtained from the following equation

E= ai (KLOC)bi*EAF

  = 3.2(12)1.05*1.2169 = 52.91 PM

Development time D = Ci (E) di

= 2.5(52.91)0.38= 11.29 M

  • Using the following equations and referring table 7, phase wise cost and schedule estimates can be calculated.

Ep = up E

Dp= tp D

Since size is only 12 KLOC, it is an organic small model. Phase wise effort distribution is given below:

System Design= 0.16*52.91= 8.465 PM

Detailed Design= 0.26*52.91= 13.756 PM

Module Code & Test= 0.42*52.91= 22.222 PM

Integration & test = 0.16*52.9= 8.465 PM

 

Now phase wise development time duration is

System Design = 0.19*11.29= 2.145 M

Detailed design = 0.24*11.29= 2.709 M

Module Code & Test = 0.39*11.29= 4.403 M

Integration & Test = 0.18*11.29= 2.032 M

 

 

Q2 - Explain why a design with low coupling helps maintainability

Answer:

One of the most important goals of object oriented design is to have high cohesion classes and loose coupling between these classes.

Coupling refers to links between separate units of a program. In object oriented programming, if two classes depend closely on many details of each other, we say they are tightly coupled.

Coupling is a measure of the interdependence between classes. If every object has a reference to every other object, then there is tight coupling, and this is undesirable. Because there´s potentially too much information flow between objects. Loose coupling is desirable. It means that objects work more independently of each other. Loose coupling minimizes the "ripple effect" where changes in one class cause necessity for changes in other classes.

Cohesion, on the other hand, refers to the number and diversity of tasks that a class is designed for. If a class is responsible for a few related logical tasks, we say it has high cohesion.

Cohesion is a measure of strength of the association of variables and methods within a class. High cohesion is desirable because it means the class does one job well. Low cohesion is bad because it indicates that there are elements in the class which have little to do with each other. Modules whose elements are strongly and genuinely related to each other are desired. Each method should also be highly cohesive. Most methods have only one function to perform. Don´t add extra instructions into methods that cause it to perform more than one function.

Loose coupling makes it possible to:

  1. Understand one class without reading others
  2. Change one class without affecting others
  3. Thus: improves maintainability

 

High cohesion makes it easier to:

  • Understand what a class or method does
  • Use descriptive names
  • Reuse classes or methods

 

  1. Discuss the significance and use of requirement engineering. What are the problems in the formulation of requirements?

Answer:

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements . . . No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later”.

So wrote Fred Brooks in 1987, and so it remains today [Davis 1990a, Faulk 1997a]. "The inability to produce complete, correct, and unambiguous software requirements is still considered the major cause of software failure today".

Requirements are statements of what the system must do, how it must behave, the properties it must exhibit, the qualities it must possess, and the constraints that the system and its development must satisfy. The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as

  • a condition or capability needed by a user to solve a problem or achieve an objective
  • a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  • a documented representation of a condition or capability as in definition 1 or 2 [IEEE 1990a]

 

Requirements engineering emphasizes the use of systematic and repeatable techniques that ensure the completeness, consistency, and relevance of the system requirements. Specifically, requirements engineering encompasses requirements elicitation, analysis, specification, verification, and management, where

  • Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user´s needs and constraints for the system.
  • Requirements analysis is the process of refining the user´s needs and constraints.
  • Requirements specification is the process of documenting the user´s needs and constraints clearly and precisely.
  • Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
  • Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)

 

Requirements engineering is complex because of the three roles involved in producing even a single requirement: the requestor (referred to as the "user" in the IEEE definition), the developer (who will design and implement the system), and the author (who will document the requirements). Typically, the requestor understands the problem to be solved by the system but not how to develop a system. The developer understands the tools and techniques required to construct and maintain a system but not the problem to be solved by that system. The author needs to create a statement that communicates unambiguously to the developer what the requestor desires. Hence, requirements address a fundamental communications problem.

 

 

 Assignment C

Question No.  1          Marks - 10

________________________________________

The development is supposed is supposed to be processed linearly through the phases

Options                      

  1. Spiral Model
  2. Waterfall Model
  3. Prototyping Model
  4. None of the above

 

 

Question No.  2          Marks - 10

________________________________________

The DFD depicts                                          

Options                      

  1. Flow of data
  2. Flow of control
  3. Both A & B
  4. None of the above

 

 

Question No.  3          Marks - 10

________________________________________

The most desirable form of coupling is                  

Options                      

  1. Control Coupling
  2. Common Coupling
  3. Data Coupling
  4. Content Coupling

 

 

Question No.  4          Marks - 10

________________________________________

If failure intensity is 0,005 failures/hour during 10 hours of operation of software, its reliability can be expressed as  

Options          

  1. 90
  2. 92
  3. 95
  4. 98

 

 

Question No.  5          Marks - 10

________________________________________

Regression testing is primarily related to               

Options          

  1. Functional Testing
  2. Data Flow Testing
  3. Development Testing
  4. Maintenance Testing

 

 

Question No.  6          Marks - 10

________________________________________

Which one is not a step of requirement engineering?       

Options                      

  1. Requirement Elicitation
  2. Requirement Analysis
  3. Requirement Design
  4. Requirement Documentation

 

 

Question No.  7          Marks - 10

________________________________________

Which one is not a requirement elicitation technique?     

Options          

  1. Interviews
  2. The use case approach
  3. FAST
  4. Data flow diagram

 

 

Question No.  8          Marks - 10

________________________________________

Level-O DFD is similar to    

Options                      

  1. Use case diagram
  2. Context diagram
  3. System diagram
  4. None of the above

 

 

Question No.  9          Marks – 10

________________________________________

The DFD depicts      

Options                      

  1. Flow of data
  2. Flow of control
  3. Both (a) & (b)
  4. None of the above

 

 

Question No.  10        Marks - 10

________________________________________

Which one is not a size measure for software?      

Options          

  1. LOC
  2. Function Point
  3. Cyclamate Complexity
  4. Halstead’s Program Length

 

 

Question No.  11        Marks - 10

________________________________________

Estimation of size for a project dependent on       

Options                      

  1. Cost
  2. Schedule
  3. Time
  4. None of the above

 

 

Question No.  12        Marks - 10

________________________________________

COCOMO-II was developed at      

Options                      

  1. University of Maryland
  2. University of Southern California
  3. IBM
  4. At & T Bell Labs

 

 

Question No.  13        Marks - 10

________________________________________

How many stages are in COCOMO-II?     

Options                      

  1. 2
  2. 3
  3. 4
  4. 5

 

 

Question No.  14        Marks - 10

________________________________________

Which one is not a risk Management Activity?     

Options                      

  1. Risk Assessment
  2. Risk control
  3. Risk Generation
  4. None of the above

 

 

Question No.  15        Marks – 10

________________________________________

The worst type of cohesion is          

Options                      

  1. Temporal Cohesion
  2. Coincidental Cohesion
  3. Logical Cohesion
  4. Sequential Cohesion(Solved by www.solvezone.in ; please do not copy, plagiarism warning; contact: 8882309876)

 

 

Question No.  16        Marks - 10

________________________________________

. Which one is not a strategy for design?   

Options                      

  1. Bottom up design
  2. Top Down design
  3. Embedded design
  4. Hybrid design

 

 

Question No.  17        Marks - 10

________________________________________

A system that does not interact with external environment is called       

Options                      

  1. Closed System
  2. Logical System
  3. Open System
  4. Hierarchal System

 

 

Question No.  18        Marks - 10

________________________________________

The extent to which different modules are dependent upon each other is called           

Options          

  1. Coupling
  2. Cohesion
  3. Modularity
  4. Stability

 

 

Question No.  19        Marks - 10

________________________________________

Which one is not a category of software metrics? 

Options                      

  1. Product metrics
  2. Process metrics
  3. Project metrics
  4. People metrics

 

 

Question No.  20        Marks - 10

________________________________________

 

Which one is not a measure of software science theory?  

Options                      

  1. Vocabulary
  2. Volume
  3. Level
  4. Logic

 

 

Question No.  21        Marks - 10

________________________________________

Minimal implementation of any algorithm was given the following name by Hallstead:          

Options          

  1. Volume
  2. Potential Volume
  3. Effective Volume
  4. None of the above

 

 

Question No.  22        Marks - 10

________________________________________

 

Which one is the International standard for size measure?         

Options                      

  1. LOC
  2. Function Point
  3. Program Length
  4. None of the above

 

 

Question No.  23        Marks - 10

________________________________________

. Fault is         

Options          

  1. Defect in the program
  2. Mistake in the program
  3. Error in the program
  4. All of the above

 

 

Question No.  24        Marks - 10

________________________________________

As the reliability increases, failure intensity           

Options                      

  1. Decreases
  2. Increases
  3. No effect
  4. None of the above

 

 

Question No.  25        Marks - 10

________________________________________

Software Quality is   

Options                      

  1. Conformance to requirements
  2. Fitness for the purpose
  3. Level of satisfaction
  4. All of the above

 

 

Question No.  26        Marks - 10

________________________________________

How many product quality factors have been proposed in McCall quality model?      

Options                      

  1. 2
  2. 11
  3. 3
  4. 6

 

 

Question No.  27        Marks - 10

________________________________________

 

Which one is not a software quality model?          

Options                      

  1. McCall Model
  2. Boehm Model
  3. ISO9000
  4. ISO9126

 

 

Question No.  28        Marks - 10

________________________________________

NHPP stands for      

Options          

  1. Non Homogeneous Poisson Process
  2. Non Heterogeneous Poisson Process
  3. Non Homogeneous Poisson Product
  4. Non Heterogeneous Poisson Product

 

 

Question No.  29        Marks - 10

________________________________________

Total numbers of maturing levels in CMM are     

Options                      

  1. 1
  2. 5
  3. 3
  4. 7

 

 

Question No.  30        Marks - 10

________________________________________

CMM is developed by          

Options                      

  1. Harvard University
  2. Cambridge University
  3. Carnegie Mellon University
  4. Maryland University

 

 

Question No.  31        Marks - 10

________________________________________

Software reliability is defined with respect to        

Options          

           

  1. Time
  2. Speed
  3. Quality
  4. None of the above

 

 

Question No.  32        Marks - 10

________________________________________

Software mistakes during coding are known as:  

Options                      

  1. Failures
  2. Defects

Review

Average user rating

4.8 / 5

Rating breakdown

5
80% Complete (danger)
1
4
80% Complete (danger)
1
3
80% Complete (danger)
0
2
80% Complete (danger)
0
1
80% Complete (danger)
0

January 29, 2015
This was nice in buy
Assignment from solve zone is probably one of the first preference of students.

October 09, 2016
This was nice in buy
I recommend a website that was really helpful throughout your session.

March 19, 2017
Some day ago
This was nice in buy
This was good in buy . I found all the answer correct and meaningful and had scored good marks
Back to top