SOFTWARE ENGINEERING AND SOFTWARE PROJECT MANAGEMENT

1. What is instability?

Software instability measures indicate the necessity to modify a software

module (class, package, subsystem, etc) due to changes in other related software
entities. ... In the latter case, software reconstruction could be necessary and the
maintainability becomes harder because of dependencies.

2. What is project tracking and project closure?

The Project Closure Phase is the fourth and last phase in the project life
cycle. ... Project Closure involves handing over the deliverables to your
customer, passing the documentation to the business, cancelling supplier
contracts, releasing staff and equipment, and informing stakeholders of the
closure of the project.

A project tracking system assists you to recognize all of the tasks that are
required to complete your project successfully on time. The project tracking
system provides a highly-standarized, automated technique of budget and
planning management across a diverse group of activities

3. Define user and system requirements.

User requirements are statements, in a natural language plus diagrams, of what

services the system is expected to provide to system users and the
constraints under which it must operate. ... System requirements are more
detailed descriptions of the software system's functions, services, and
operational constraints.

4. Discuss incremental delivery.

incremental delivery (Figure 2.10) is an approach to software development where some

of the developed increments are delivered to the customer and deployed for use in their
working environment. In an incremental delivery process, customers define which of the
services are most important and which are least important to them. A number of
delivery increments are then defined, with each increment providing a subset of the
system functionality. The allocation of services to increments depends on the service
priority, with the highest priority services implemented and delivered first.

Once the system increments have been identified, the requirements for the services to
be delivered in the first increment are defined in detail and that increment is developed.
During development, further requirements analysis for later increments can take place,
but requirements changes for the current increment are not accepted.

Once an increment is completed and delivered, it is installed in the customer’s normal

working environment. They can experiment with the system, and this helps them clarify
their requirements for later system increments. As new increments are completed, they
are integrated with existing increments so that system functionality improves with each
delivered increment.

Incremental delivery has a number of advantages:

1. Customers can use the early increments as prototypes and gain experience that
informs their requirements for later system increments. Unlike prototypes, these
are part of the real system, so there is no relearning when the complete system is
available.
2. Customers do not have to wait until the entire system is delivered before they
can gain value from it. The first increment satisfies their most critical
requirements, so they can use the software immediately.
3. The process maintains the benefits of incremental development in that it should
be relatively easy to incorporate changes into the system.
4. As the highest priority services are delivered first and later increments then
integrated, the most important system services receive the most testing. This
means that customers are less likely to encounter software failures in the most
important parts of the system.

5. Define deployment: and Explain its principles.

Deployment represents the installation or running of a new version of code on a

server — going “live” with the software. A release is the software form of this new
version. It is intended for an audience beyond developers, either others in the
organization or customers.

 Get your data in order. One of the biggest hurdles a software deployment team
encounters is jumbled data. ...
 Gather the right credentials and team members. ...
 Bring in an expert. ...
  Make a plan and be realistic. ...
 Test, test, test. ...
 Be patient.

6. What are the reasons occurs to drop the Software project?

Common Software Failure Causes

Most software projects fail completely or partially because they don’t
meet all their requirements. These requirements can be the cost,
schedule, quality, or requirements objectives. According to many studies,
the failure rate of software projects ranges between 50% – 80%.

Common Software Failure Causes

There are a variety of causes for software failures but the most common
are: [2]

 Lack of user participation

 Changing requirements
 Unrealistic or unarticulated project goals
 Inaccurate estimates of needed resources
 Badly defined system requirements
 Poor reporting of the project’s status
 Lack of resources
 Unmanaged risks
 Poor communication among customers, developers, and users
 Use of immature technology
 Inability to handle the project’s complexity
 Sloppy development practices
 Poor Project Management
 Stakeholder politics
 Lack of Stakeholder involvement
 Commercial pressures

7. List the content of a technical plan.

The analysis described above will produce a number of practical requirements that will
be fed into the next stage of the planning process. These requirements might add
activities to the project and might involve the acquisition of items of software or
hardware or the adoption of particular methodologies which might require start"
training. As these recommendations imply certain costs, they should be recorded
formally.

A preliminary version of this technical plan can be produced by a software house to help
in the preparation of the bid for a contract. In some cases, it may actually be shown to
the potential customer in order to show the basis for the bid price and generally to
impress the customer with the soundness of the approach the software house intends
to adopt. The technical plan is likely to have the following contents.

1. Introduction and summary of constraints:

(a) character of the system to be developed;

(b) risks and uncertainties of the project;

(c) user requirements concerning implementation.

2. Recommended approach:

(a) selected methodology or process model;

(b) development methods;

(c) required software tools;

(d) target hardware/software env ironment.

3. Implementation:

(a) required development environment:

(b) required maintenance environment;

(c) required training.

4. Implications:
(a) project products and activities - these will have an effect on the schedule duration
and overall project effort;

(b) financial - this report will be used to produce costings.

8. Mention the strategies for risk reduction

 9. What are the requirements to be gathered for a public deciding on its automation?

To help clients and developers manage the process of requirements gathering,

we recommend these 5 steps:
 Step 1: Understand Pain Behind The Requirement. ...
 Step 2: Eliminate Language Ambiguity. ...
 Step 3: Identify Corner Cases. ...
 Step 4: Write User Stories. ...
 Step 5: Create a Definition Of “Done”
 10. What are the objective of program inspection?

Software inspection is a control technique for ensuring that the

documentation produced during a given phase remains consistent
with the documentation of the previous phases and respects
preestablished rules and standards.
The purpose of software inspection is to look for defects (of
understanding, interpretation, translation, etc.), deviations, especially
regarding quality clauses, absences or abundances etc., and to
provide the elements to make corrections. Software inspection is not
designed to make corrections. In order to be effective, software
inspection must be prepared and carried out by a separate team from
the realization team.
Software inspection is divided into two types of inspection/review:
–
the document inspection/review: we are interested in the
documents produced for a given phase. The inspection will focus
on the quality, the correctness and the relevance of the
document(s);
–
the inspection/review of the code: there is interest in the items of
type “computer file”: model, program source files, test scenarios,
etc.

11. What do you mean by the term Cost Estimation related to Software Engineering?