Scribd Logo
Upload

Welcome to Scribd!

  • 56 views

    Assignment No. - 1 On Software Engineering: Submitted To:-Lect Amandeep Sir Submitted by

    Uploaded by

    Prashant Raghav
    The document provides responses to 3 questions related to software engineering. 1. It discusses guidelines for collecting software metrics, including that metrics should be simple, empirically persuasive, consistent, use consistent units, be programming language independent, and provide quality feedback. Function points are given as an example. 2. Methods for sizing software like fuzzy logic sizing, function points, standard components, and change sizing are described. 3. The benefits of a metrics baseline are outlined, including more accurate estimates, data from many projects, consistent measures, and similar applications between baseline and new work. Consistency, accuracy, and sufficient data are important for an effective baseline.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOC, PDF, TXT or read online from Scribd

    Assignment No. - 1 On Software Engineering: Submitted To:-Lect Amandeep Sir Submitted by

    Uploaded by

    Prashant Raghav
    56 views8 pages
    The document provides responses to 3 questions related to software engineering. 1. It discusses guidelines for collecting software metrics, including that metrics should be simple, empirically persuasive, consistent, use consistent units, be programming language independent, and provide quality feedback. Function points are given as an example. 2. Methods for sizing software like fuzzy logic sizing, function points, standard components, and change sizing are described. 3. The benefits of a metrics baseline are outlined, including more accurate estimates, data from many projects, consistent measures, and similar applications between baseline and new work. Consistency, accuracy, and sufficient data are important for an effective baseline.

    Original Title

    b39

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    DOC, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document provides responses to 3 questions related to software engineering. 1. It discusses guidelines for collecting software metrics, including that metrics should be simple, empirically persuasive, consistent, use consistent units, be programming language independent, and provide quality feedback. Function points are given as an example. 2. Methods for sizing software like fuzzy logic sizing, function points, standard components, and change sizing are described. 3. The benefits of a metrics baseline are outlined, including more accurate estimates, data from many projects, consistent measures, and similar applications between baseline and new work. Consistency, accuracy, and sufficient data are important for an effective baseline.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOC, PDF, TXT or read online from Scribd
    Download as doc, pdf, or txt
    56 views8 pages

    Assignment No. - 1 On Software Engineering: Submitted To:-Lect Amandeep Sir Submitted by

    Uploaded by

    Prashant Raghav
    The document provides responses to 3 questions related to software engineering. 1. It discusses guidelines for collecting software metrics, including that metrics should be simple, empirically persuasive, consistent, use consistent units, be programming language independent, and provide quality feedback. Function points are given as an example. 2. Methods for sizing software like fuzzy logic sizing, function points, standard components, and change sizing are described. 3. The benefits of a metrics baseline are outlined, including more accurate estimates, data from many projects, consistent measures, and similar applications between baseline and new work. Consistency, accuracy, and sufficient data are important for an effective baseline.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOC, PDF, TXT or read online from Scribd
    Download as doc, pdf, or txt
    of 8

    ASSIGNMENT NO.

    ---1
    On
    Software engineering

    Submitted To:-
    Lect Amandeep sir
    Submitted by

    Name:-Prashant Raghav
    Roll no.:- RE3004B39
    Section:- E3004 Group:- 2
    HOME WORK-1\

    CAP324- Software Engineering

    PART –A

    1. 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.

    2. 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.

    3. 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
    1. 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.

    2. 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.

    3. 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.

    You might also like