Se imp questions 🙋‍♀️

 Imp questions: Imp questions

1.)

The Spiral model:

• It’s a hybrid model that couples the iterative nature of prototyping model and controlled and

systematic aspect of waterfall model.

• It provides potential for rapid development of more complex versions of software. It is a part

evolutionary model.

• A spiral model is divided into a set of framework activities. Each framework activity represents one

segment of the spiral path.

As this process begins, the software team performs activities that are implied by a circuit around the

spiral in a clockwise direction, beginning at the center.

Anchor path milestones – a combination of work products and conditions are attained along

the path of spiral.

The positives and negatives of Spiral model

Positives are:

 The spiral model is a realistic approach to the development of large- complex systems.

 It helps developer to understand and react to the risks at each evolutionary levels.

 It sees prototype as one of risk reducing mechanism, and it enable the developer to use

prototyping approach at every evolutionary levels.

Problems are: It is very difficult to convince a customer (particularly in contract situations) that the model

is controllable.

• It demands risk assessment expertise and relies on this expertise on success. If a major risk is

uncovered, problems will occur.

2).

The RAD Model:

 It is an incremental process model that emphasizes a short development cycle.

 It is a high speed adoption of the waterfall model, in which rapid software development is

achieved by using a component based development.

 If customer requirements are full understood and project scope is constrained, the RAD process

enables a development team to create a “fully functional system” within a very short period of

time. (Ex:- 60 to 90 days)

Like other process models, RAD model maps into process framework activities.

1. Communication & Planning: helps to understand business problem

and information characteristics that the software must accommodate.

2. Modeling: It encompasses three major phases:

1. Business modeling

2. Data modeling

3. Process modeling

3. Construction: emphasizes the use of pre-developed software components and automatic code

generation.

4. Deployment: initiates subsequent iteration.

Drawbacks of RAD Model

 For large and scalable projects (continuous development) RAD model requires more human

resources to create more number of teams.

 If developers and customers are not committed to the rapid-activities that are necessary to

complete the system within a short-time, the entire system will fail.

 If a system cannot be properly modularized, the RAD will be problematic.

 RAD may not be suitable if technical risks are high.

 If performance is an issue, and high performance can be achieved through tuning the interfaces

among components, the RAD is useless.

3).

BUILDING THE REQUIREMENTS MODEL

The intent of the analysis model is to provide a description of the required informational,functional, and

behavioral domains for a computer-based system. The model changes dynamically as you learn more

about the system to be built, and other stakeholders understand more about what they really require.

For that reason, the analysis model is a snapshot ofrequirements at any given time.

Elements of the Requirements Model :  There are many different ways to look at the requirements for

a computer-based system. Different modes of representation force you to consider requirements from

different viewpoints—an approach that has a higher probability of uncovering omissions, inconsistencies,

and ambiguity.

Scenario-based elements : The system is described from the user’s point of view using a

scenario-based approach. For example, basic use cases and their corresponding use-case

diagrams evolve into more elaborate template-based use cases. Scenario-based elements of

the requirements model are often the first part of the model that is developed. Three levels of

elaboration are shown, culminating in a scenario-based representation.

Class-based elements. Each usage scenario implies a set of objects that are manipulated as

an actor interacts with the system. These objects are categorized into classes—a collection of

things that have similar attributes and common behaviors. Example shown in figure 5.4

Behavioral elements. The behavior of a computer-based system can have a profound effect onthe

design that is chosen and the implementation approach that is applied. Therefore, the requirements

model must provide modeling elements that depict behavior.

The state diagram is one method for representing the behavior of a system by depicting its states and

the events that cause the system to change state. A state is any externally observable mode of

behavior. In addition, the state diagram indicates actions taken as aconsequence of a particular event.

Flow-oriented elements: Information is transformed as it flows through a computer-based system.

The system accepts input in a variety of forms, applies functions to transform it, and produces output

in a variety of forms. Input may be a control signal transmitted by a transducer,a series of numbers

typed by a human operator, a packet of information transmitted on a network link, or a voluminous

data file retrieved from secondary storage. The transform(s) may comprise a single logical comparison,

a complex numerical algorithm, or a rule-inference approach of an expert system.

Requirements analysis is very critical process that enables the success of a system or software project to be assessed. Requirements are generally split into two types: Functional and Non-functional requirements.

4).

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.

Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements.

They basically deal with issues like:

• Portability
• Security
• Maintainability
• Reliability
• Scalability
• Performance
• Reusability
• Flexibility

  Following are the differences between Functional and Non Functional Requirements

  Functional Requirements	Non Functional Requirements
  A functional requirement defines a system or its component.	A non-functional requirement defines the quality attribute of a software system.
  It specifies “What should the software system do?”	It places constraints on “How should the software system fulfill the functional requirements?”
  Functional requirement is specified by User.	Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers.
  It is mandatory.	It is not mandatory.

5).What is legacy software?

Legacy software is software that has been around a long time and still fulfills a business need. It is mission critical and tied to a particular version of an operating system or hardware model (vendor lock-in) that has gone end-of-life. Generally the lifespan of the hardware is shorter than that of the software. As time goes on, the hardware gets harder to maintain but is kept because it is installed and (for now) working and has proven too complex and/or expensive to replace

6).

The fundamental activities of a software process are:

• Specification
• Design and Implementation
• Validation
• Evolution

7) 

COMMUNICATION PRINCIPLE  :

Effective communication (among technical peers, with the customer and other stakeholders, and with project managers) is among the most challenging activities that confront software engineer. In this context, we discuss communication principles that apply equally to all forms of communication that occur within a software project.

Principle #1: Listen.

Principle #2: Prepare before you communicate.


Principle #3: Someone should facilitate the activity.
.

Principle #4: Face–to-face communication is best.

Principle #5: Take notes and documentation decisions:


Principle #6: Stay focused, modularize your discussion.

Principle #7: If something is unclear, draw a picture.


Principle #8: (a) Once you agree to something, move on; (b) If you can’t agree to something, move on; (c) If a feature or function is unclear and cannot be clarified at the moment move on.

Principle #9: Negotiation is not a contest or a game. It works best when both parties win.

8).

An important part of the Unified Modeling Language (UML) is the capability for drawing use case diagrams. Use cases are used during the analysis phase of a project to identify system functionality. They separate the system into actors and use cases. Actors represent roles that are played by users of the system. Users may be humans,other computers,or even other software systems. In this article, I will examine the importance of Use cases with a help of a simple case

 study.

What Use Cases Do 1.    They hold Functional Requirements in an easy to read and tracking format. 2.    They represent the goal of an interaction between an actor and the system. 3.    They are multi-level, one use case can use/extent the functionality of another. What Use Cases Do Not Do 1.    They don't specify user interface design. They specify the intent, not the action Detail. 2.    They don't specify implementation detail. Definitions 1.    Actor: An actor is something with behavior, such as a person, computer system, or organization. 2.    Scenario: A scenario is a specific sequence of actions and interactions between actors and the system under discussion; it is also called a use case instance 9. 10)Design guidelines are sets of recommendations on how to apply design principles to provide a positive user experience. Designers use such guidelines to judge how to adopt principles such as intuitiveness, learnability, efficiency and consistency so they can create compelling designs and meet and exceed user needs. 1 2. 3 Style - e.g., brand logos, colors Layout - e.g., grid or list structure User interface (Ul) components - e.g., menus, buttons 4 5 Text - e.g., font, tone, labels/fields Accessibility - e.g., Aria markup for disabled users 6. Design Patterns - e.g., forms