ALLAMA IQBAL OPEN UNIVERSITY, ISLAMABAD

Form for Assignment Submission

This Part is for Students

Name of Student

Muhammad Zubair Anwar

Name of Tutor

Mr. Ayub Sheikh

Roll Number

BI503842

Tutors Full Address Department

University, Islamabad.

of

Computer

Science,

Allama

Iqbal

Open

Students Full Address

Muhammad Zubair Anwar, DEO (IT Cell), NAB
HQ, Ataturk Avenue, G-5/2, Islamabad.
Name of Course

Software Engineering

Course Code

3575

Assignment Number

Semester

Spring 2016

Last Date of Submission

30-09-2016

1 (One)

Submitted Date

This Part is for Tutors

Name of Study Centre
Islamabad

Online (DCS) AIOU

District

Islamabad

Date of Receiving
Q.No.
Obtain
ed
Marks

10

11

12

13

14

15
Obtain
ed
Marks
Total
Marks

Tutors Suggestions

Signature

Returning Date

Q.1 a) Explain why Professional Software is not just the programs that are developed
for a customer?
Answer:

Software Engineering
According to IEEE [IEE93] software engineering is defined as Software
Engineering: (1) The application of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance of software; that is, the application
of engineering to software. (2) The study of approaches as in (1).
Any professional software that is developed according to the processes and
methods provided by software engineering is not only a software developed for
customer.

Software
According to Roger S. Pressman a software is (1) instructions (computer
programs) that when executed provide desired function and performance, (2) data
structures that enable the programs to adequately manipulate information, and (3)
documents that describe the operation and use of the programs. There is no
question that other, more complete definitions could be offered. But we need more
than a formal definition.

Characteristics of Software
As software is a logical entity rather than a physical entity, the characteristics
of software are somewhat different than physical entities. We can describe them as
under.

Software is developed or Engineered Not Manufactured

Although some similarities exist between software development and
hardware manufacture, the two activities are fundamentally different. In both
activities high quality is achieved through good design, but the manufacturing
phase for hardware can introduce quality problems that are nonexistent (or easily
corrected) for software. Both activities depend on people, but the relationship
between people applied and word accomplished is entirely different. Bothe activities
require the construction of a product, but the approaches are different.
Software costs are concentrated in engineering. This means that software
projects cannot be managed as if they were manufactured projects.
In the mid-1980s, the concept of the software factory was introduced in the
literature (e.g., [MAN84], [TAJ84]). It is important to note that this term does not
imply that hardware manufacturing and software development are equivalent.
Rather, the software factory concept recommends the use of automated tools for
software development.

Software doesnt wear out.

As hardware is a physical entity it wears out by time and use. Any physical
entity that is in use by us wears out by time and use. For instance, we have a fan in
our home it can perform its desired activity for a certain time effectively, but after
few years the performance will be low and the functionality will be ended because
its hardware has been wore out by usage.
The software on the other hand is a logical entity. It does not wear out but it
deteriorated because of obsolescence. New technology and new frameworks those
do not support old software make the software to be upgraded according to the new
technology.

Most Software is custom-based, rather than being assembled from existing

components
While designing and manufacturing hardware, the engineer uses already
designed and manufactured parts to manufacture a new hardware. These parts are
called ICs (Integrated Circuits). Each IC has its own model number printed on it and
has a unique functionality.
While developing software, software designers are not afforded the luxury.
With few exceptions, there are no catalogs of software components. It is possible to
order off-the-shelf software, but only as a complete unit, not as components that
can be reassembled into new programs. Although much has been written about
software reusability, we are only beginning to see successful implementations of
the concept.

Conclusion
With the help of above discussion, we can see that software is a product and
has different characteristics than a physical entity. While developing software if
professionally developed through software engineering process, as the quality is the
bedrock of software engineering, professional software will serve its purpose
efficiently rather than the software that is developed for a customer and no services
and maintenance, the problems will occur and solution will not be available.
Professional software on other hand are engineered through a process in which
maintenance is a part of the software engineering process and it continues until the
customer is fully satisfied with the results.

Q.1 b) What is the most important difference between generic software product
development and custom software development? What might this mean in practice
for users of generic software products?
Answer:
Firstly, in defining the differences between generic and custom software it is
important to define what generic and custom software actually is;

Generic Software
Generic software is software that can perform many different tasks and is not
limited to one particular application. For example, a spreadsheet application is
generic because it is useful for multiple purposes without modification, such as a
calculating tool for engineers or a finance tool for accountants.
Generic software is readily available to the public. Developers design bespoke
software, also known as custom software, on the other hand, for specific
applications. Developers create this kind of software to suit one particular clients
needs instead of the general public. Unlike generic software, it is not usually widely
available for sale on the public market.

Custom Software
Customized software is a computer program or web application that is
specifically designed for a particular purpose, department or company. The software
is owned by the customer and can incorporate features from other software
programs. Customized software is written and designed to meet the clients specific
business processes.
With customized software, the customer owns the rights and the license to
the product. The client can resell the software to other interested parties.
Customized software can combine features from other existing software with
features that a company needs. Many companies choose customized software in
order to eliminate repetitive tasks, enhance the maintenance of precise data,
improve sharing of information and get real-time results.

Difference between Generic Software Development and

Custom Software Development
Now that these two types of software have briefly been defined, a
comparison between them is given below.

Generic Software Development

Generic software development differs from custom software development
mainly in the intended users and functions for those users that will be contained
within the software. Generic software has to include as many functions as possible

as it will have a very wide use base, and will need to provide functionality and
usability to that wider range of users. However, because of the wide use base of
generic software it also needs to be quite concise with the functions that are
included; as having too many functions available to users, who may not be the best
experts on computers, would probably affect the ease of use of the software.
Generic software also has to be developed to be very reusable and have
components that can be easily modified or added to at a later date, making the
software as upgradable as possible so it can have a longer useful lifetime.

Custom Software Development

The development of custom made software differs from this because the uses
of the software are for a lot more specific of a customer base, and usually would
include components that would need to be freshly written for the software; as if
generic components already existed to perform the requirements of the users then
they would have brought off the shelf software. Custom software development is
usually a lot more based around communication with the specific needs of the users
the software is being created for, to insure the finish product will meet the needs of
the end user, whilst still being made of separate components that make the
software as upgradable as possible. However, as custom software is usually
developed by one company/group of developers for a specific user, the
upgradability and maintainability of the software will always be limited as if the
knowledge from the original creators is lost, possibly through hiring of new IT
support staff, then the new staff would take a long time to get to grips with the
custom software and would risk damage to it when making modifications or
upgrades to it at a later date.

Q. 2 Explain the following process models with diagrams. Also elaborate the
strength and weaknesses of each model:

a)

a)

Waterfall Process Model

b)

Spiral Process Model

Waterfall Process Model

The waterfall model is a sequential software development process model that

follows the following defined phases:
1.
2.
3.
4.
5.
6.
7.
8.

Conception
Initiation
Analysis
Design
Construction
Testing
Production/Implementation
Maintenance
Using the software development life cycles (SDLC) common steps, the
waterfall model enforces moving to the next phase only after completion of the
previous phase. Returning to a previous phase is frowned upon unless there is a
clear need to do so.

Conception
Initiation
Analysis
Design
Construction
Testing
Production/
Implementati
on
Maintenance

As its name implies, the phases in the waterfall model consistently progress
downward. These phases should be followed in sequence to be effective, and in
some industries such as construction and manufacturing the process must be
followed.
In theory, the waterfall model sounds like a good practice, but it has been
criticized by many in the software development industry. First, an SDLC phase
cannot be perfected before moving to the following phase. Also, in its literal form
this model lacks flexibility for requirement and design adjustments, which makes it
highly difficult for programmers and developers to integrate design adjustments.
However, there are some sound principles from the waterfall model that can
be applied to successful software development. This is a partial list of these
principles:

Problems can be solved more easily if they are more clearly defined.
Large amounts of code are more traceable if they are structured.
Human work should always be verified.
A good project life-cycle plan improves the development process.
System documentation is a byproduct of the development process, and is not
done later, as an afterthought.

The waterfall model was an early attempt to provide structure, metrics and
control to the development of large and complex application systems, usually
mainframe systems.

b)

Spiral Process Model

Spiral model is an evolutionary software process model which is a

combination of an iterative nature of prototyping and controlled and systematic
aspects of traditional waterfall model.
This model was originally proposed by Boehm. It provides the potential for
rapid development of incremental versions of the software.
In Spiral model, software development takes place in series of developed
releases. In initial stage iterations, the release or model might be a paper model or
a prototype. In the later stages a more complete version of software is actually
produced.

Communication

Planning

Risk Analysis

Customer Evaluation

Construction and Release

Engineering

A spiral model is made up of set different framework activities made by the

software engineering team. Take a look at the following spiral model diagram:

A spiral model is divided into number of framework activities, also called task
regions. Every framework activity represents one section of the spiral path. As the
development process starts, the software team perform activities that are indirect
by a path around the spiral model in a clockwise direction. It begins at the center of
spiral model.

Typically, there are between three and six task regions. The above figure
depicts a spiral model that contains 6 task regions.

Phases of Spiral Model (Tasks Regions)

Customer communication-tasks required to establish effective

communication between developer and customer.

Planning-tasks required to define resources, timelines and other project

related information.

Risk analysis tasks required to assess both technical and management

risks.

Engineering tasks required to build one or more representations of the

application.

Construction and release tasks required to construct, test, install, and

provide user support.

Customer evaluation-tasks required to obtain customer feedback

based on evaluation of the software representations created during the
engineering stage and implemented during the installation stage.
Each of the regions is populated by a set of work tasks, called a task set, that
are adapted to the characteristics of the project to be undertaken. For small
projects, the number of work tasks and their formality is low. For larger, more critical
projects, each task region contains more work tasks that are defined to achieve a
higher level of formality. In all cases, the umbrella activities e.g. software
configuration management and software quality assurance are applied.

Advantages of Spiral Model

The spiral model is a realistic approach to the development of large-scale
systems and software. Check out some of the advantages of spiral model:
1. Estimates (i.e. budget, schedule, etc.) become more realistic as work
progresses, because more important issues are discovered earlier.
2. It is abler to cope with the changes that software development generally
entails.
3. Software engineers can get their hands in and start working on a project
earlier.

Disadvantages of Spiral Model

With advantages there are also some disadvantages of spiral model. Here are some
of the disadvantages of spiral model:
1. Highly customized limiting re-usability.
2. Applied differently for each application.
3. Risk of not meeting, budget or schedule.

Applications
The spiral model is mostly used in large projects. The military had adopted
the spiral model for its Future Combat Systems program.
The spiral model thus may suit small software applications and not a
complicated distributed, inter operable, system of systems.
It is also reasonable to use the spiral model in projects where business goals
are unstable but the architecture must be realized well enough to provide high
loading and stress ability.
For example, the Spiral Architecture Driven Development is the spiral based
Software Development Life Cycle (SDLC) which shows one possible way how to
reduce the risk of non-effective architecture with the help of an in conjunction with
the best practices from other models.

Q. 3 a) What are the important (fundamental) ideas of software engineering that

apply to all types of software systems?

Software system
A software system is a system of intercommunicating components based on
software forming part of a computer system (a combination of hardware and
software). It consists of a number of separate programs, configuration files, which
are used to set up these programs, system documentation, which describes the
structure of the system, and user documentation, which explains how to use the
system.
While a computer program is a set of instructions (source, or object code) a
software system has many more components such as specification, test results,
end-user documentation, maintenance records, etc.
The term software system should be distinguished from the terms
computer program and software. The term computer program generally refers
to a set of instructions (source, or object code) that perform a specific task.
However, a software system generally refers to a more encompassing concept with
many more components such as specification, test results, end-user documentation,
maintenance records, etc.
The use of the term software system is at times related to the application of
systems theory approaches in the context of software engineering. A software
system consists of several separate computer programs and associated
configuration files, documentation, etc., that operate together. The concept is used
in the study of large and complex software, because it focuses on the major
components of software and their interactions. It is also related to the field of
software architecture.
Software systems are an active area of research for groups interested in
software engineering in particular and systems engineering in general. Academic
journals like the Journal of Systems and Software (published by Elsevier) are
dedicated to the subject.
The ACM Software System Award is an annual award that honors people or an
organization for developing a software system that has had a lasting influence,
reflected in contributions to concepts, in commercial acceptance, or both. It has
been awarded by the Association for Computing Machinery (ACM) since 1983, with a
cash prize sponsored by IBM.

Categories
Major categories of software systems include those based on application
software, programming software and system software, although the distinction can
sometimes be difficult. Examples of software systems include operating systems,

computer reservations systems, air traffic control systems, military command and
control systems, telecommunication networks, content management systems,
database management systems, expert systems, embedded systems etc.

Software Engineering
In order to build software that is ready to meet the challenges of the twentyfirst century, you must recognize a few simple realities:
Software has become deeply embedded in virtually every aspect of our
lives, and as a consequence, the number of people who have an interest
in the features and functions provided by a specific application8 has
grown dramatically. When a new application or embedded system is to be
built, many voices must be heard. And it sometimes seems that each of
them has a slightly different idea of what software features and functions
should be delivered. It follows that a concerted effort should be made to
understand the problem before a software solution is developed.
The information technology requirements demanded by individuals,
businesses, and governments grow increasing complex with each passing
year. Large teams of people now create computer programs that were
once built by a single individual. Sophisticated software that was once
implemented in a predictable, self-contained, computing environment is
now embedded inside everything from consumer electronics to medical
devices to weapons systems. The complexity of these new computerbased systems and products demands careful attention to the interactions
of all system elements. It follows that design becomes a pivotal activity.
Individuals, businesses, and governments increasingly rely on software
for strategic and tactical decision making as well as day-to-day operations
and control. If the software fails, people and major enterprises can
experience anything from minor inconvenience to catastrophic failures. It
follows that software should exhibit high quality.
As the perceived value of a specific application grows, the likelihood is
that its user base and longevity will also grow. As its user base and timein-use increase, demands for adaptation and enhancement will also grow.
It follows that software should be maintainable.
These simple realities lead to one conclusion: software in all of its forms and
across all of its application domains should be engineered. And that leads us to the
software engineering.
Software Engineering: (1) The application of a systematic, disciplined,
quantifiable approach to the development, operation, and maintenance of software;
that is, the application of engineering to software. (2) The study of approaches as in
(1).

And yet, a systematic, disciplined, and quantifiable approach applied by

one software team may be burdensome to another. We need discipline, but we also
need adaptability and agility.

Software Engineering Practice

Generic
framework
activitiescommunication,
planning,
modeling,
construction, and deploymentand umbrella activities establish a skeleton
architecture for software engineering work. But how does the practice of software
engineering fit in? In the sections that follow, youll gain a basic understanding of
the generic concepts and principles that apply to framework activities.

Generic Principles of Software Engineering

The dictionary defines the word principle as an important underlying law or
assumption required in a system of thought. Well discuss principles at many
different levels of abstraction. Some focus on software engineering as a whole,
others consider a specific generic framework activity (e.g., communication), and still
others focus on software engineering actions (e.g., architectural design) or technical
tasks (e.g., write a usage scenario). Regardless of their level of focus, principles
help you establish a mind-set for solid software engineering practice. They are
important for that reason. David Hooker [Hoo96] has proposed seven principles that
focus on software engineering practice as a whole. They are reproduced in the
following paragraphs:

The First Principle: The Reason It All Exists

A software system exists for one reason: to provide value to its users. All
decisions should be made with this in mind. Before specifying a system
requirement, before noting a piece of system functionality, before determining the
hardware platforms or development processes, ask yourself questions such as:
Does this add real value to the system? If the answer is no, dont do it. All other
principles support this one.

The Second Principle: KISS (Keep It Simple, Stupid!)

Software design is not a haphazard process. There are many factors to
consider in any design effort. All design should be as simple as possible, but no
simpler. This facilitates having a more easily understood and easily maintained
system. This is not to say that features, even internal features, should be discarded
in the name of simplicity. Indeed, the more elegant designs are usually the simpler
ones. Simple also does not mean quick and dirty. In fact, it often takes a lot of
thought and work over multiple iterations to simplify. The payoff is software that is
more maintainable and less error-prone.

The Third Principle: Maintain the Vision

A clear vision is essential to the success of a software project. Without one, a
project almost unfailingly ends up being of two [or more] minds about itself.
Without conceptual integrity, a system threatens to become a patchwork of

incompatible designs, held together by the wrong kind of screws.... Compromising

the architectural vision of a software system weakens and will eventually break
even the well-designed systems. Having an empowered architect who can hold the
vision and enforce compliance helps ensure a very successful software project.

The Fourth Principle: What You Produce, Others Will Consume

Seldom is an industrial-strength software system constructed and used in a
vacuum. In some way or other, someone else will use, maintain, document, or
otherwise depend on being able to understand your system. So, always specify,
design, and implement knowing someone else will have to understand what you are
doing. The audience for any product of software development is potentially large.
Specify with an eye to the users. Design, keeping the implementers in mind. Code
with concern for those that must maintain and extend the system. Someone may
have to debug the code you write, and that makes them a user of your code.
Making their job easier adds value to the system.

The Fifth Principle: Be Open to the Future

A system with a long lifetime has more value. In todays computing
environments, where specifications change on a moments notice and hardware
platforms are obsolete just a few months old, software lifetimes are typically
measured in months instead of years. However, true industrial-strength software
systems must endure far longer. To do this successfully, these systems must be
ready to adapt to these and other changes. Systems that do this successfully are
those that have been designed this way from the start. Never design yourself into a
corner. Always ask what if, and prepare for all possible answers by creating
systems that solve the general problem, not just the specific one.14 This could very
possibly lead to the reuse of an entire system.

The Sixth Principle: Plan Ahead for Reuse

Reuse saves time and effort. Achieving a high level of reuse is arguably the
hardest goal to accomplish in developing a software system. The reuse of code and
designs has been proclaimed as a major benefit of using object-oriented
technologies. However, the return on this investment is not automatic. To leverage
the reuse possibilities that object-oriented [or conventional] programming provides
requires forethought and planning. There are many techniques to realize reuse at
every level of the system development process. Planning ahead for reuse reduces
the cost and increases the value of both the reusable components and the systems
into which they are incorporated.

The Seventh principle: Think!

This last principle is probably the most overlooked. Placing clear, complete
thought before action almost always produces better results. When you think about
something, you are more likely to do it right. You also gain knowledge about how to
do it right again. If you do think about something and still do it wrong, it becomes a
valuable experience. A side effect of thinking is learning to recognize when you

dont know something, at which point you can research the answer. When clear
thought has gone into a system, value comes out. Applying the first six principles
requires intense thought, for which the potential rewards are enormous. If every
software engineer and every software team simply followed Hookers seven
principles, many of the difficulties we experience in building complex computer
based systems would be eliminated.

Q. 3 b) Explain the layered approach of software engineering with the help of

suitable example.

The primary goal of software engineering

The primary goal of software engineering is to build a high-quality product in
a timely manner. It aims to achieve this primary goal by using an engineering
approach.
Engineering involves a set of fundamental principles that should always be
followed. These include explicit activities for understanding the problem and
communicating with the customer, defined methods for representing a design, the
best practices for implementing the solution, and sound strategy and tactics for
testing. If the basic principles are followed, it results in technology products of high
quality.

Software engineering as a collection of practices

To achieve the goal of building high-quality products within schedule,
software engineering employs a set of practices to:

Understand the problem

Design a solution
Implement the solution correctly
Test the solution
Manage the above activities to achieve high quality

Software engineering represents a formal process that incorporates a series

of well-defined methods for the analysis, design, implementation, and testing of
software and systems. In addition, it may encompass a broad array of project
management methods and techniques for software quality assurance (SQA) and
software configuration management (SCM).

Relevance of software engineering

Now that you understand what software engineering is, let us discuss its
relevance in the present scenario.
Today, software products are built with a level of urgency that was not seen in
previous years. The top priority for companies is to reduce the time-to-market,
which in turn requires rapid development.
Software engineering is perceived by some practitioners as being too formal,
time-consuming, and structured for the flexibility required during development
today. They argue that they cannot afford the formality of an engineering approach
for building software because they need to develop products rapidly. People raising
such objections view engineering as a static discipline that they think, cannot adapt

to the changing needs of business and industry. The truth however is, software
engineering is adaptive and is, therefore, relevant for anyone building a software
product.

Software engineering is adaptive

Let us now look at the layers of software engineering.
Software engineering is an adaptive technology and not a fixed methodology.
It is a philosophy that can be adapted and applied across all software development
activities and application domains.
Software engineering provides a broad array of options that professionals can
choose from to build high-quality products. However, there is no single engineering
approach or a set of software engineering processes, methods or tools to build a
software product.
The software engineering approach, including the processes, methods, and
tools, can and should be adapted to the product, the people who build it, and the
business environment.
Software professionals, therefore, should not be dogmatic about software
engineering. It is not a religion and there are no absolutes
The layers of software engineering
A software engineering approach relies heavily on an organizational
commitment to quality because it is not possible to incorporate software
engineering in an organization that is not focused on achieving quality.
We can view software engineering as a set of layered components, with the
foundation being the organizations quality approach, that is, its Total Quality
Management (TQM) philosophy.
The layers resting on this foundation are:

Process: A framework that helps the project manager control project

management and engineering activities
Methods: The technical activities required for the creation of work
products
Tools: The automated assistance for processes and methods

We will now discuss each of these layers in detail.

The process layer

The process layer defines the process that will be used to build the software
and the activities and tasks that a project manager will have to manage. Therefore,
it forms the basis for planning and managing all the project activities for building a

product. The process layer is essentially the harness into which we place the
technology for building the software product.
The process layer:

Enables the project manager to plan for the successful execution of the
project
Provides practitioners the context of their work

We can view all the activities, including the technical activities, as being part
of the process. In addition, any resources, including tools, used for building the
software also fit in the process. The process layer is, therefore, the foundation of
software engineering and supports the methods and tools layers.

Importance of a process
A process is helpful because it provides clarity on how the work has to be
performed. Any complex set of human activities can become chaotic if there is no
guidance for the people performing the activities. A defined process answers the
following questions:

Who communicates with whom?

How are inter-dependent activities coordinated?
Who is responsible for what work?
Who produces what work products, and how is each assessed for
goodness?

A process:

Identifies all the software engineering activities and tasks

Defines the flow of work among activities and tasks
Identifies the work products that are produced
Specifies the quality checkpoints that are required

A defined process
Some people view software development with a perspective that it requires
artistic skill and craftsmanship and is inherently chaotic. They resist the idea of
using a defined process because they view it as being cumbersome and
bureaucratic, and therefore hindering creativity.
While there is no doubt that software development requires creativity, most
of the quality software in the industry is produced by the coordinated effort of more
than one person. For any team effort, coordinated control is a better alternative
than anarchy. The road-map provided by a process is useful for people who build
software products or manage projects.
All approaches to building software have a process, but in many cases, it is
ad hoc, invisible, and chaotic. Good software engineering makes the software
process more visible, predictable, and useful to those who build software.

Features of the process layer

The following features are included in the process layer.

The common process framework (CPF)

Software engineering activities and tasks
Quality checkpoints
Work product definitions
Project management
Software quality assurance (SQA)
Software configuration management (SCM)
Project monitoring
Measurement and metrics

The methods layer

You have seen that the process layer identifies the engineering tasks that
must be performed to build high-quality software.
The next layer, the methods layer focuses on the technical activities that
must be performed to accomplish the engineering tasks. It provides the technical
how to and covers the fundamental engineering activities.
Building software involves performing a broad array of technical activities.
The methods layer contains the methods defined to perform these activities
effectively. It focuses on how the technical activities are to be performed. The
practitioners use the methods to perform the fundamental engineering activities
that are required to build the software.

Technical activities in the methods layer

Let us obtain an overview of the technical activities that are addressed by the
methods layer. The fundamental technical activities required to build software are:

Analysis: Analysis is the foundation of all engineering work that follows.

During analysis, the model of what is required from the software is
created.
Design: Design activities follow analysis and translate the analysis model
into how the product will provide this functionality through software.
Code: Once the design is complete, coding translates the design model
into an executable form.
Test: The testing process helps to uncover errors in the code and the
underlying design.

In addition, several umbrella or support activities are also performed as part

of the software process.

Technical methods in the methods layer

For various process activities, the methods layer contains the corresponding
set of technical methods to be used. These encompass a set of rules, the modes of

graphical or text-based representation, and the related guidelines for assessing the
quality of the information represented. Let us look at an example.
Consider the activity understand and describe a problem that may be
present in the process layer. For this, we need to define the technical methods for
attributes such as:

Communication with the customer

Requirements elicitation
Modeling
Description of the data objects to be manipulated, the functionality to be
delivered, and the system behavior

We may decide that the technical method we will use for analysis will be
object-oriented analysis and that the specifications will be documented using the
standard template of the organization.

Selecting a method
To define a methods layer, we need to select suitable methods from the wide
range of available methods.
Consider the analysis and design activities. There is a wide variety of
methods available for these, with exhaustive books written for each. The software
project team should select the method that is most appropriate to the problem, the
development environment, and the knowledge and background of the team
members.
For example, analysis and design methods are used to produce models that
represent the problem and the design. These models are depicted using text and
graphics. Both the technical team and the customer should be able to understand
and use the depiction. The models should also be usable as input for subsequent
engineering activities. The methods selected, therefore, must provide a clear and
concise engineering description of how the models will be created and depicted.

The tools layer

The tools layer provides support to the process and methods layers by
focusing on the means that automate the various manual activities. Tools can be
used for automating the following activities.

Project management activities

Technical methods used in software engineering
General system support
Framework for other tools

Automation helps remove the tedium from the work, reduces the chances of
mistakes, and makes it easier to use good software engineering practices. When
tools are used, documentation becomes an integral part of the work done instead of

being an additional overhead activity. Hence, documentation does not have to be

performed as a separate activity. Tools can be used for performing project
management activities as well as technical activities.

Tools for various activities

Various tools can be used for performing project management and technical
activities. The list of tools is as follows:

Project management tools

Change control tools
Analysis and design tools
Code generation tools
Testing tools
Re-engineering tools
Documentation tools
Repository support tools
Prototyping tools

These tools support the process and methods layer in various activities.

Example of what a tool can do

Let us take an example of a project management tool. Some of the activities
that can be performed by the tool include:

The definition of resources

The definition of tasks
The allocation of resources to tasks
The scheduling of tasks and milestones
The tracking of actual versus scheduled tasks
The depiction of tasks as a Gantt chart
The generation of management reports based on the actual data. These
reports may be a project summary, the critical tasks and milestones, the
slipping tasks, the over-budgeted tasks, a list of over-allocated resources,
and who does what and when.

Integrated tools
We have seen a list of the tools that are a part of the tools layer. The tools
layer can also use integrated tools, that is, tools that function as an integrated set
and use a common repository.
Integrated tools help to provide comprehensive support for development.
They use a repository for storing all the software engineering work products, and
this repository can be used by all the tools.
We can look at software engineering as a set of activities performed in a
workshop called integrated project support environment (IPSE) with the tools
supporting it collectively called computer-aided software engineering (CASE). CASE
can be a single tool supporting a specific activity or an integrated set of tools

supporting a complex environment that includes software, hardware, and a software

engineering database.

Q. 4 Giving reasons for you answer based on the type of system being developed,
suggest the most appropriate generic software process model that might be
used as a basis for managing the development of the following systems:
a)
b)
c)
d)

a)

A system to control hybrid car.

A virtual reality system to support software maintenance.
A university accounting system that replaces an existing system.
An interactive travel planning system that helps users plan journeys with
the lowest environmental impact.

A system to control hybrid car.

Let us analyze the problem here.
Engineering already applied to the design of hybrid car and we have to
develop a system for control hybrid car
Requirements are known and are not changing over time to time.
Design is completed as engineering model has been designed
completely

The linear sequential model (Waterfall Model) is most appropriate for

development of software regarding a system to control hybrid car.

b) A virtual reality system to support software

maintenance.
Let us analyze the problem here.
System requires a complete knowledge of the software to be
maintained
Proper documentations and design manuals will be available to use
Error detection technology is required for maintenance.
Several changes during development of the system are expected.
Prototyping model is most appropriate for the given situations, as we can see
there would be a lot of rethinking and testing of the software is involved.

c) A University Accounting System that replaces the

existing system
Let us analyze the problem here.

A system is already developed

Modules of old system are available to reuse
Database structure is available to reuse
Minor updating and new requirement inclusion is required

A Rapid Application Development Model is most appropriate for the situation

as modules for reuse are available for development of new system as well as the
time required for development of the system is comparatively short as new system
is always required to deployed in time.

d) An interactive travel planning system that helps

users plan journeys with the lowest environmental
impact.
Let us analyze the problem here.
A thorough negotiation is required to plan the system
System is a complex one that requires many more systems to be used
for instance environment judgments etc.
A lot of upgradations will be required as the user of the system is
general public and changes will be communicated through feedback.
A Concurrent Development Model is most appropriate for the situation, as the
system requires a lot of changes at any phase and at any case.

Q. 5 Effective software project management focuses on the four Ps: people,

product, process, and project. Explain the role of each P in software engineering.

Effective Software Project Management

Why a software is created? Is it for some divine purpose or, is it for the sake
of the software itself? It is simple enough to understand that software is created to
make work easy for the people who use them. Therefore, the human aspect of
software should not be over looked. All project managers who tend to overlook or,
undermine this important aspect quite inevitably lands the project in soup. The
success of software project management depends upon the 4 Ps of the
management spectrum. They are the People, Product, Process and the Project. Each
has almost equal impact on the end product that is delivered for use.

People Aspect
What is the most essential requirement without which software development
per se will not take place at all? This essential requirement refers to the people
involved in software development, or, in other words, the developers. It is absolutely
essential to have highly skilled and motivated developers to execute the project at
hand. The People factor makes a crucial difference to the quality of the project.
Besides the project team the People factor also refers to the stake holders who
participate in the software process. The people management maturity model
defines key practice areas for software people like recruitment, selection,
performance management, training, compensation, career development,
organization, team development etc.
The following categories of people are involved in the software process.

Senior Managers
Project Managers
Practitioners
Customers
End Users

Senior Managers define the business issue. Project Managers plan, motivate,
Organize and control the practitioners who do the Software work. Practitioners
deliver the technical skills that are necessary to engineer a product or application.
Customer specifies the requirements for the software to be developed. End Users
interact with the software once it is released.

Product Aspect
Before planning a project, the objectives and scope of the product has to be
established. One should also consider the alternative solutions and the technical
and management constraints. It is for the developer to understand the wants and
the requirements of the clients / customers and then organize the gathered data
and create the end product based on this. It is also essential for the two to meet in

order to decide what the product must include, its objective and scope. Once the
objective and scope of product is established, alternative solutions can be
considered.

Process Aspect
The process aspect of software development provides a framework which
helps in establishing a comprehensive plan for developing the software. Framework
for any project will have to be made for the sake of convenience irrespective of the
size of the project. One cannot say that one project is too small to have a framework
dedicated to it. The generic phases that characterize the software process are
definition, development and support. This is applicable to all kinds of software. It is
the responsibility of the project manager to decide the process model that is most
appropriate for the customers, and the work team, the characteristics of the product
and the project environment.

Project Aspect
Everything at the end of the day depends upon how successful the project
finally becomes. The project is the entirety of software development. To make the
software project successful one must not wait till the problems show up, but
determine what problems may arise, beforehand. Some of the common signs by
which problems in the project can be determined are poorly defined product scope,
the software people not understanding customer needs, unrealistic deadlines,
resistant users etc.