Notes of Software engineering

UNIT 1:-

PROJECT MANAGEMENT
Project management involves planning and organization of a
company's resources to move a specific task, event, or duty towards
completion. It typically involves a one-time project rather than an
ongoing activity, and resources managed include personnel, finances,
technology, and intellectual property. A project manager helps to
define the goals and objectives of the project
Importance 0f project management:
Clearly defines the plan of the project before it begins:

 Creates a base for teamwork:

 Resources are maximised:
 Helps to manage integration:
 Helps to keep control of costs:
 Helps to manage change:

THE MANAGEMENT SPECTRUM:

The management spectrum describes the management of a software project or how
tomake a project successful. It focuses on the four P’s; people, product, process
and project.Here, the manager of the project has to control all these P’s to have a
smooth flowin the project progress and to reach the goal
The four P’s of management spectrum has been described briefly in below.

The People:
People of a project includes from manager to developer, from customer to end
user. But mainly people of a project highlight the developers. It is so important to
have highly skilled and motivated developers that the Software Engineering
Institute has developed a People Management Capability Maturity Model (PM-
CMM), “to enhance the readiness of software organizations to undertake
increasingly complex applications by helping to attract, grow, motivate, deploy,
and retain the talent needed to improve their software development capability”.
Organizations that achieve high levels of maturity in the people management area
have a higher likelihood of implementing effective software engineering practices.

The Product:

Product is any software that has to be developed. To develop successfully, product

objectives and scope should be established, alternative solutions should be
considered, and technical and management constraints should be identified.
Without this information, it is impossible to define reasonable and accurate
estimates of the cost, an effective assessment of risk, a realistic breakdown of
project tasks or a manageable project schedule that provides a meaningful
indication of progress.
The Process:
A software process provides the framework from which a comprehensive plan for
software development can be established. A number of different tasks sets— tasks,
milestones, work products, and quality assurance points—enable the framework
activities to be adapted to the characteristics of the software project and the
requirements of the project team. Finally, umbrella activities overlay the process
model. Umbrella activities are independent of any one framework activity and
occur throughout the process.

The Project:
Here, the manager has to do some job. The project includes all and everything of
the total development process and to avoid project failure the manager has to take
some steps, has to be concerned about some common warnings etc.

THE PEOPLE:
The people is one of the four P’s of Software Management Spectrum. It includes
all the people from senior manager to practitioners, from customer to end user.
Though it is not definite but people of the project do the most. Some of the terms
are described below:-

The Players:
The software process (and every software project) is populated by players who can
be categorized into one of five constituencies,

1. Senior Managers: They define the business issues that often have significant
influence on the project.
2. Project Managers: They must plan, motivate, organize, and control the
practitioners who do software work.
3. Practitioners: They deliver the technical skills that are necessary to engineer a
product or application.
4. Customers: They specify the requirements for the software to be engineered
and other stakeholders who have a peripheral interest in the outcome.
5. End-users: They interact with the software once it is released for production
use.

Team Leaders:
Project management is a people-intensive activity, and for this reason, competent
practitioners often make poor team leaders. A good team leader should have some
abilities described in the MOI model of leadership in below,
1. Motivation: The ability to encourage (by “push or pull”) technical people to
produce to their best ability.
2. Organization: The ability to mold existing processes (or invent new ones) that
will enable the initial concept to be translated into a final product.
3. Ideas or innovation: The ability to encourage people to create and feel creative
even when they must work within bounds established for a particular software
product or application.

COORDINATION AND COMMUNICATION ISSUES

There are many reasons that software projects get into trouble. The scale of many
development efforts is large, leading to complexity, confusion, and significant
difficulties in coordinating team members. Uncertainty is common, resulting in a
continuing stream of changes that ratchets the project team. Interoperability has
become a key characteristic of many systems. New software must communicate
with existing software and conform to predefined constraints imposed by the
system or product.

These characteristics of modern software—scale, uncertainty, and

interoperability— are facts of life. To deal with them effectively, a software
engineering team must establish effective methods for coordinating the people who
do the work. To accomplish this, mechanisms for formal and informal
communication among team members and between multiple teams must be
established. Formal communication is accomplished through “writing, structured
meetings, and other relatively noninteractive and impersonal communication
channels” . Informal communication is more personal.

Formal, impersonal approaches include software engineering documents and

deliverables (including source code), technical memos, project milestones,
schedules, and project control tools , change requests and related documentation ,
error tracking reports, and repository data.

Formal, interpersonal procedures focus on quality assurance activities applied to

software engineering work products. These include status review meetings and
design and code inspections.

Informal, interpersonal procedures include group meetings for information

dissemination and problem solving and “collocation of requirements and
developmentstaff.”

Electronic communication encompasses electronic mail, electronic bulletin

boards, and by extension, video-based conferencing systems.

Interpersonal networking includes informal discussions with team members and

those outside the project who may have experience or insight that can assist team
members.

PRODUCT:-
the Product is what we're actually building. What's our solution to the problem at
hand? Half of engineering is making sure you're building the right product and
have the ability to actually build it. For software engineers, that means coming up
with a software solution and being able to code it up properly.
Product Engineering is the process of innovating, designing, developing, testing
and deploying a software product. The advent of Web 2.0 technologies and utility
based software delivery through Software as a Service (SaaS) has led to the
process of gradual transformation of client enabling engineering services from
traditional software engineering to product engineering. Product engineering takes
care of the entire product life cycle from the innovation phase, starting from the
idea being conceived to the deployment and user acceptance testing phase.
The various phases of product engineering are:

 Product Ideation
 Product Architecture
 Product Design
 Product Testing
 Product Migration and Porting
 Technical Support
 Sustaining Engineering
 Professional Services
 SOFTWARE PROCESS
A software process (also knows as software methodology) is a set of related
activities that leads to the production of the software. These activities may involve
the development of the software from the scratch, or, modifying an existing system.
W5hhprinciples:-

Why is the system being developed? The answer to this question enables all
parties to assess the validity of business reasons for the software work. Stated in
another way, does the business purpose justify the expenditure of people, time, and
money?

What will be done, by when? The answers to these questions help the team to
establish a project schedule by identifying key project tasks and the milestones that
are required by the customer.

Who is responsible for a function? The answer to this question helps accomplish
this.

Where are they organizationally located? Not all roles and responsibilities eside
within the software team itself. The customer, users, and other stakeholders also
have responsibilities.

How will the job be done technically and managerially? Once product scope is
established, a management and technical strategy for the project must be defined.

How much of each resource is needed? The answer to this question is derivedby
developing estimates based on answers to earlier questions.

Boehm’s W5HH principle is applicable regardless of the size or complexity of a

software project. The questions noted provide an excellent planning outline for the
project manager and the software team.

RAD(RAPID APPLICATION DEVELOPMENT)

Rapid application development is a software development methodology that uses
minimal planning in favor of rapid prototyping. A prototype is a working model
that is functionally equivalent to a component of the product.
RAD projects follow iterative and incremental model and have small teams
comprising of developers, domain experts, customer representatives and other IT
resources working progressively on their component or prototype.
 SDLC RAD model has following phases

 Business Modeling
 Data Modeling
 Process Modeling
 Application Generation
 Testing and Turnover

PROCESS PROJECT
A “process” has an objective that is typically A “project” has an objective or outcome to be
defined around the ongoing operation of the accomplished and the project ends when that
process. objective is accomplished. That objective
For example, “provide ongoing maintenance might be broadly-defined and might change
for GM vehicles” or be further elaborated as the project is in
progress.
For example, “find a replacement ignition
switch that will solve the problem with GM
vehicles".
A “process” is generally ongoing and doesn’t A “project” has a beginning and an end
normally have an end. (although the beginning and end may not be
well-defined when the project starts and the
end might be a long time in the future).
A “process” is a repetitive sequence of tasks The sequence of tasks in a “project” is not
and the tasks are known at the outset since it normally repetitive and may not be known at
is repetitive. the outset of the project.

PROCESS MANAGEMENT PROJECT MANAGEMENT

Process management is focused on Project management is focused on managing

managing a process such as a software a project typically using some process in
development process. Such a process might achieving some kind of desired end result.
be used across a variety of projects. Every project follows some kind of process
Process management might involve some even though it may not be formally defined.
project management to define and improve
the process.

Process management has an emphasis on Project management has an emphasis on

increasing "repeatability" of the tasks, achieving the end result that the project is
improving efficiency (decreasing time intended to accomplish.
needed, reducing cost), and improving Higher efficiency is harder to achieve since
quality of the work product produced by the it might require custom tools and methods
process (including consistency in quality). that can only be developed if the project was
 turned into a repetitive process.

Here’s a similar distinction between “process management” and “project

management”:

In simple, terms, “process management” is focused on managing existing business

processes as efficiently and effectively as possible – it’s associated with managing
the current way the business operates. “Project management” is associated with
managing some kind of change in the way a business operates effectively such as
introducing a new product, implementing new processes, etc.

PROJECT METRICS –
 CLEANROOM SOFTWARE ENGINEERING
 It is an engineering approach which is used to build correctness in developed
software.
 The main concept behind the cleanroom software engineering is to remove the
dependency on the costly processes.
 The cleanroom software engineering includes the quality approach of writing the
code from the beginning of the system and finally gathers into a complete a
system.
Following tasks occur in cleanroom engineering:

1. Incremental planning
 In this task, the incremental plan is developed.
 The functionality of each increment, projected size of the increment and the
cleanroom development schedule is created.
 The care is to be taken that each increment is certified and integrated in proper
time according to the plan.
2. Requirements gathering
 Requirement gathering is done using the traditional techniques like analysis,
design, code, test and debug.
 A more detailed description of the customer level requirement is developed.
3. Box structure specification
 The specification method uses box structure.
 Box structure is used to describe the functional specification.
 The box structure separate and isolate the behaviour, data and procedure in each
increment.
4. Formal design
 The cleanroom design is a natural specification by using the black box structure
approach.
 The specification is called as state boxes and the component level diagram called
as the clear boxes.
5. Correctness verification
 The cleanroom conducts the exact correctness verification activities on the design
and then the code.
 Verification starts with the highest level testing box structure and then moves
toward the design detail and code.
 The first level of correctness takes place by applying a set of 'correcting
questions'.
 More mathematical or formal methods are used for verification if correctness does
not signify that the specification is correct.
6. Code generation, inspection and verification
 The box structure specification is represented in a specialized language and these
are translated into the appropriate programming language.
 Use the technical reviews for the syntactic correctness of the code.
7. Statical test planning
 Analyzed, planned and designed the projected usages of the software.
 The cleanroom activity is organized in parallel with specification, verification and
code generation.
8. Statistical use testing
 The exhaustive testing of computer software is impossible. It is compulsory to
design limited number of test cases.
 Statistical use technique execute a set of tests derived from a statistical sample in
all possible program executions.
 These samples are collected from the users from a targeted population.
9. Certification
 After the verification, inspection and correctness of all errors, the increments are
certified and ready for integration.
 CLEANROOM APPROACH AND STRATERGY

Cleanroom differs from other formal methods in that it doesn't require

mathematically defined requirements. These requirements are divided into tagged
statements for traceability. The process of tagging requirements in small verifiable
statements allows for tracing and verification of each requirement throughout the
process. Cleanroom Software Engineering is comprised of four different
processes:

UNIT 2:
Formal Methods:
The formal methods model is concerned with the application of a mathematical
technique to design and implement the software. This model lays the foundation
 for developing a complex system and supporting the program development. The
formal methods used during the development process provide a mechanism for
eliminating problems, which are difficult to overcome using other software process
models. The software engineer creates formal specifications for this model.
Generally, the formal method comprises two approaches, namely, property
based and model-based. The property-based specification describes the
operations performed on the system. In addition, it describes the relationship that
exists among these operations. A property-based specification consists of two
parts: signatures, which determine the syntax of operations and an equation, which
defines the semantics of the operations through a set of equations known
as axioms. The model-based specification utilizes the tools of set theory, function
theory, and logic to develop an abstract model of the system. In addition, it
specifies the operations performed on the abstract model. The model thus
developed is of a high level and idealized. A model-based specification comprises
a definition of the set ofstates of the system and definitions of the legal operations
performed on the system to indicate how these legal operations change the current
state.

Formal method can be applied at various points through development process

1 specification:- formal methods may be used to give description of the system to
be developed the formal description can be used to guide further development
activites additionaly it can be used to verify that their requirements for the system
is being developed have been completely accurately specify
2 development :-once formal specification has been produced the specification
may be used as a guide while the system is being developed durig design process
3 verification once a formal specification has been developed the specification may
be used as a basis for providing properties of specification

Advantages and Disadvantages of Formal Methods Model

Advantages Disadvantages
1. Discovers ambiguity,
1. Time consuming and expensive.
incompleteness, and inconsistency in2. Difficult to use this model as a
the software. communication mechanism for non
2. Offers defect-free software. technical personnel.
3. Incrementally grows in effective 3. Extensive training is required since
 solution after each iteration. only few developers have the
4. This model does not involve high essential knowledge to implement
complexity rate. this model.
5. Formal specification language
semantics verify self-consistency.

Z-SPECIFICATION LANGUAGE
Z has been developed at Oxford University since the late 1970’s by members of
the Programming Research Group (PRG) within the Computing LaboratoryIt is a
typed language based on set theory and first order predicate logic.There is nothing
very unusual about the mathematics employed, although a few operators
have been added as experience has been gained in its use. Z includes a schema
notation to aid the structuring of specifications. This provides the framework for a
textual combination of sections of mathematics (known as schemas) using schema
operators.
Each error condition is described as a Z schema which may
subsequently be included by individual operations as required. Each operation is
normally allocated a page for its description, although occasionally
this can spill over onto a second page for more complicated operations. The
description is split into different sections.

RE ENGINEERING:
• Restructuring or rewriting part or all of a system without changing its
functionality
• Applicable when some (but not all) subsystems of a larger system require
frequent maintenance
• Reengineering involves putting in the effort to make it easier to maintain
• The reengineered system may also be restructured and should be re-documented

Economics of Reengineering:
• Cost of maintenance: cost annual of operation and maintenance over application
lifetime
• Cost of reengineering: predicted return on investment reduced by cost of
implementing changes and engineering risk factors
• Cost benefit: Cost of re engineering - Cost of maintenance
Re-engineering advantages:
Reduced risk
There is a high risk in new software development. There may be development
problems, staffing problems and specification problems
Reduced cost
The cost of re-engineering is often significantly less than the costs of developing
new software