U9 Assignment of

Software Engineering

Homework-1

Submitted by: Submitted To:

Name: Abhishek Mr. Amandeep sir

Section: E - 3004

Roll_No: RE3004B58
Group : 2

Part – A

Q1: Take a suitable example to develop a software and implement the waterfall Model technique in it to develop the software ?

Ans: The waterfall model shows a process, where developers are to follow these phases in order: 1. Requirements specification (Requirements analysis) 2. Software Design 3. Integration 4. Testing (or Validation) 5. Deployment (or Installation) 6. Maintenance

In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes (which may involve a formal change control process). Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters of other more "flexible" models.

The waterfall model proceeds from one phase to the next in a sequential manner. For example, one first completes requirements specification, which after sign-off are considered "set in stone." When requirements are completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow—this design should be a plan for implementing the requirements given. When the design is complete, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors.

Q2: Differentiate between RAD and component based development by taking some suitable example?

Ans: RAD (Rapid Action Development)

The RAD model is linear sequential software development process that emphasizes an extremely short development cycle. The RAD model is a high speed adaption of the linear sequential model in which rapid development is achieved by using component based construction approach. It has following phases

• Business modeling • Data modeling • Process modeling • Application generation • Testing and Turnover

Component Based Development
Commercial off - the – shelf (COTS) software components, developed by vendors who offer them as products, provides targeted functionality with well-defined interfaces that enable the component to be integrated into the software that is to be built. The component based development model incorporates many of the characteristics of the spiral model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component based development model construct applications from pre-packaged software components.

Component based development (CBD) consisting of developing software applications from loosely coupled components has the following distinct advantages:

1. Software Reuse - Encourages higher level of software reuse. 2. Simplifies Testing - Allows testing to be carried out by first testing each of the components before testing the assembly of components. 3. Simplifies system maintenance and modification - Since each of the components are loosely coupled you are free to upgrade and/or add components as needed without effecting other parts of the system. 4. Higher Quality - Since a component can be built and then continuously improved upon by an expert or organization the quality of a component based application will improve over time.

Q3: What do we look for when choosing someone to lead a software project? Justify your statement by giving some example.

Ans: Project management is a people intensive activity, and for this reason, competent practitioners often make poor team leaders. They simply don’t have the right mix of people skills. And yet, as Edgemon states unfortunately and all too frequently it seems individual just fall into a project manager role and become accidental project managers.

Model of leadership

Motivation : The ability to encourage (by “push or pull”) technical people to produce to their best ability.

Organization : The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.

Ideas of innovation : The ability to encourage people to create and feel creative evan when they must work within bounds established for a particuler software product or application.

Problem Solving :

Managerial identity : A good project manager must take charge of the project. She must have the confidence to assume control when necessary and the assurance to all good technical people to follow their instinct.

Achievement : A complete manager must reward initiative and accomplishment to optimize the productivity of a project teem. She must demonstrate through own action that controlled risk taking will not be punished.. Influence and team building : An effective project manager must be able to read people she must be able to understand verbal and nonverbal signals and react to the needs of the people sending the signal. The manager must remain under control in high stress situations.

PART-B

Q4:What guidelines should be applied when we collect software

metrics ? Give suitable examples.

Ans:- There are 100 of metrics have been proposed for computer software, but not all provide practical support to the software engineer. There are defines a set of attributes that should be encompassed by effective software metrics.

• Simple and computable:- it should be relatively easy to learn how to derive the metrics, and its computation should not demand inordinate effort or time.

• Empirically and intuitively persuasive:- the metrics should satisfy the engineer’s intuitive notion about the product attribute under consideration.

• Consistent and objective:- The metrics should always yield result that are unambiguous.

• Consistent in its use of unit and dimension:- the mathematical computation of the metric should use measure that do not lead to bizarre combinations of unit.

• Programming language independent:- metrics should be based on the requirement model, the design model, or the structure of the program itself. They should not be dependent on the vagaries of programming language syntax or semantics.

• An effective mechanism for high-quality feedback:- that is the metrics should provide you with information that can lead to a higher-quality end product.

Although most of the metrics satisfy these attribute, some commonly used metrics may fail to satisfy one or two of them. An example is the function point- a measure of the “functionality” delivered by the software. It can be argued that the consistent and objective attribute fails because an independent 3rd party may not be able to derive the same function point value as a colleague using the same information about the software, thus we reject the FP.

Q5: How do we size the software that we are planning to build ? Justify your statements by giving some suitable examples.

Ans:- There are some approaches to the sizing problem • “Fuzzy logic” sizing:- this approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range.

• Function point sizing:- the planner develops estimates of the information domain characteristics.

• Standard component sizing:- software is composed of a number of different “standard component” that are generic to a particular application area.

• Change sizing:- this approach is used when a project encompasses the use of existing software that must be modified in some way as part of a project.

Q6: With the help of examples explain that ‘what benefits does

metrics Baseline provide to a software engineer ?’

Ans: By establishing a metrics baseline benefits can be k obtained that at the process, project, and product levels. Yet the information that is collected need not be fundamentally different. The matrices baseline consist of data collected form past software development.

To be an effective aid in process improvement and/or cost and effort estimation, baseline data must have the following attributes.

1. Data must be reasonably accurate – “guestimates” about past projects are to be avoided.

2. Data should be collected for as many projects as possible.

3. Measures must be consistent (for example, a line of code must be interpreted consistently across all projects for which data are collected.)

4. Application should be similar to work that is to be estimated – it makes little sense to use a baseline for batch information systems work to estimate a real-time embedded application.