1. What do you understand by the term Software Development Life Cycle?

Why is it important to adhere to a life cycle model while developing a large

software system?

2. Write short note (a)Software Cost Estimation  (b)Team Structure

3. What do you understand by software project scheduling? Write down the

software project scheduling techniques.

4. Explain on the following: (a)    Problem partitioning (b)   Abstraction

5. What is software design? Discuss the design principles in detail.

Ans 3

Project Scheduling
Project scheduling is concerned with the techniques that can be employed to manage the
activities that need to be undertaken during the development of a project.
Scheduling is carried out in advance of the project commencing and involves:
•    identifying the tasks that need to be carried out;
•    estimating how long they will take;
•    allocating resources (mainly personnel);
•    scheduling when the tasks will occur.
Once the project is underway control needs to be exerted to ensure that the plan continues to
represent the best prediction of what will occur in the future:
•    Based on what occurs during the development;
•    Often necessitates revision of the plan.
Effective project planning will help to ensure that the systems are delivered:
•    Within cost;
•    Within the time constraint;
•    To a specific standard of quality.
Two project scheduling techniques will be presented, the Milestone Chart (or Gantt chart) and
the Activity Network.
Milestone Charts
Milestones mark significant events in the life of a project, usually critical activities which must
be achieved on time to avoid delay in the project.
Milestones should be truely significant and be reasonable in terms of deadlines (avoid using
intermediate stages).
Examples include:
•    Installation of equipment;
•    Completion of phases;
•    File conversion;
•    Cutover to the new system
Gantt Charts
A Gantt chart is a horizontal bar or line chart which will commonly include the following
features:
•    Activities identified on the left hand side;
•    Time scale is drawn on the top (or bottom) of the chart;
•    a horizontal open oblong or a line is drawn against each activity indicating estimated
duration;
•    Dependencies between activities are shown;
•    At a review point the oblongs are shaded to represent the actual time spent (an alternative
is to represent actual and estimated by 2 separate lines);
•    A vertical cursor (such as a transparent ruler) placed at the review point makes it possible
to establish activities which are behind or ahead of schedule.
 
Activity Networks
The foundation of the approach came from the Special Projects Office of the US Navy in
1958. It developed a technique for evaluating the performance of large development projects,
which became known as PERT - Project Evaluation and Review Technique. Other variations
of the same approach are known as the critical path method (CPM) or critical path analysis
(CPA).
The heart of any PERT chart is a network of tasks needed to complete a project, showing the
order in which the tasks need to be completed and the dependencies between them.
 
EXAMPLE OF ACTIVITY NETWORK
The diagram consists of a number of circles, representing events within the development
lifecycle, such as the start or completion of a task, and lines, which represent the tasks
themselves. Each task is additionally labeled by its time duration. Thus the task between
events 4 & 5 is planned to take 3 time units. The primary benefit is the identification of the
critical path.
The critical path = total time for activities on this path is greater than any other path through
the network (delay in any task on the critical path leads to a delay in the project).
Tasks on the critical path therefore need to be monitored carefully.
The technique can be broken down into 3 stages:
1. Planning:
•    identify tasks and estimate duration of times;
•    arrange in feasible sequence;
•    draw diagram.
2. Scheduling:
•    establish timetable of start and finish times.
3. Analysis:
•    establish float;
•     evaluate and revise as necessary

Ans 5

Software design is the process by which an agent creates a specification of a software

artifact, intended to accomplish goals, using a set of primitive components and subject to
constraints.Software design may refer to either "all the activity involved in conceptualizing,
framing, implementing, commissioning, and ultimately modifying complex systems" or "the
activity following requirements specification and before programming, as ... in a stylized
software engineering process."

Software design usually involves problem solving and planning a software solution. This
includes both a low-level component and algorithm design and a high-level, architecture
design.

Software design is the process of envisioning and defining software solutions to one or more
sets of problems. One of the main components of software design is the software
requirements analysis (SRA). SRA is a part of the software development process that lists
specifications used in software engineering. If the software is "semi-automated" or user
centered, software design may involve user experience design yielding a storyboard to help
determine those specifications. If the software is completely automated (meaning no user or
user interface), a software design may be as simple as a flow chart or text describing a
planned sequence of events. There are also semi-standard methods like Unified Modeling
Language and Fundamental modeling concepts. In either case, some documentation of the
plan is usually the product of the design. Furthermore, a software design may be platform-
independent or platform-specific, depending upon the availability of the technology used for
the design.

The main difference between software analysis and design is that the output of a software
analysis consists of smaller problems to solve. Additionally, the analysis should not be
designed very differently across different team members or groups. In contrast, the design
focuses on capabilities, and thus multiple designs for the same problem can and will exist.
Depending on the environment, the design often varies, whether it is created from reliable
frameworks or implemented with suitable design patterns. Design examples include operation
systems, webpages, mobile devices or even the new cloud computing paradigm.

Software design is both a process and a model. The design process is a sequence of steps
that enables the designer to describe all aspects of the software for building. Creative skill,
past experience, a sense of what makes "good" software, and an overall commitment to
quality are examples of critical success factors for a competent design. It is important to note,
however, that the design process is not always a straightforward procedure; the design model
can be compared to an architect's plans for a house. It begins by representing the totality of
the thing that is to be built (e.g., a three-dimensional rendering of the house); slowly, the thing
is refined to provide guidance for constructing each detail (e.g., the plumbing lay). Similarly,
the design model that is created for software provides a variety of different views of the
computer software. Basic design principles enable the software engineer to navigate the
design process.

The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved.
They are as follows:

Abstraction - Abstraction is the process or result of generalization by reducing the

information content of a concept or an observable phenomenon, typically in order to retain
only information which is relevant for a particular purpose. It is an act of Representing
essential features without including the background details or explanations.
Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a
macroscopic statement of function in a step-wise fashion until programming language
statements are reached. In each step, one or several instructions of a given program are
decomposed into more detailed instructions. Abstraction and Refinement are complementary
concepts.
Modularity - Software architecture is divided into components called modules.
Software Architecture - It refers to the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system. Good software architecture
will yield a good return on investment with respect to the desired outcome of the project, e.g.
in terms of performance, quality, schedule and cost.
Control Hierarchy - A program structure that represents the organization of a program
component and implies a hierarchy of control.
Structural Partitioning - The program structure can be divided into both horizontally and
vertically. Horizontal partitions define separate branches of modular hierarchy for each major
program function. Vertical partitioning suggests that control and work should be distributed top
down in the program structure.
 Data Structure - It is a representation of the logical relationship among individual elements
of data.
Software Procedure - It focuses on the processing of each module individually.
Information Hiding - Modules should be specified and designed so that information
contained within a module is inaccessible to other modules that have no need for such
information.

In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularisation, and
Hierarchy as fundamental software design principles. The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularisation, and Encapsulation) is sometimes used to refer to
these four fundamental principles.

Ans 1

SOFTWARE DEVELOPMENT LIFECYCLE (SDLC) is a systematic process for building

software that ensures the quality and correctness of the software built. SDLC process aims to
produce high-quality software that meets customer expectations. The system development
should be complete in the pre-defined time frame and cost. SDLC consists of a detailed plan
which explains how to plan, build, and maintain specific software. Every phase of the SDLC
life cycle has its own process and deliverables that feed into the next phase. SDLC stands for
Software Development Lifecycle.

SDLC stands for Software Development LifeCycle and it is the process of developing
information system with proper analysis, design, implementation and maintenance. SDLC is
said to be equal to layer two of open systems interconnection or OSI model of network
communication. This level of protocol assures proper flow of data from one level to another.
SDLC is important because it breaks down the entire life cycle of software development thus
make is easier to evaluate each part of software development and also makes it easier for
programmers to work concurrently on each phase.

The field of Software Engineering is relatively new and introduction of scientific approaches
for software development has been a recent phenomenon. As software use proliferated in late
70s and early 80s, and as programming languages evolved from assembly languages to
higher level procedural and object oriented languages, software development experts in
industry and universities started looking for ways to improve quality and reliability of their
products. The result was introduction and refinement of Software Development Life Cycle
(SDLC) and other formal development methodologies that were based on SDLC.
Moreover, SDLC, is not a technical document – rather it’s a process document. So, as such, it
is not a very technically challenging read and most readers should be able to understand the
basic concepts of phased approach to software development. Time and effort they put in
understanding SDLC would definitely be a worthwhile investment for their businesses.

Ans 4

Problem Partitioning
When solving a small problem, the entire problem can be tackled at once. The complexity of
large problems and the limitations of human minds do not allow large problems to be treated
as huge monoliths. For solving larger problems, the basic principle is the time-tested principle
of “divide and conquer.” Clearly, dividing in such a manner that all the divisions have to be
conquered together is not the intent of this wisdom. This principle, if elaborated, would mean,
“divide into smaller pieces, so that each piece can be conquered separately.”
For software design, therefore, the goal is to divide the problem into manageably small pieces
that can be solved separately. It is this restriction of being able to solve each part separately
that makes dividing into pieces a complex task and that many methodologies for system
design aim to address. The basic rationale behind this strategy is the belief that if the pieces
of a problem are solvable separately, the cost of solving the entire problem is more than the
sum of the cost of solving all the pieces.
However, the different pieces cannot be entirely independent of each other, as they together
form the system. The different pieces have to cooperate and communicate to solve the larger
problem. This communication adds complexity, which arises due to partitioning and may not
have existed in the original problem. As the number of components increases, the cost of
partitioning, together with the cost of this added complexity, may become more than the
savings achieved by partitioning. It is at this point that no further partitioning needs to be
done. The designer has to make the judgment about when to stop partitioning.
Two of the most important quality criteria for software design are simplicity and
understandability. It can be argued that maintenance is minimized if each part in the system
can be easily related to the application and each piece can be modified separately. If a piece
can be modified separately, we call it independent of other pieces. If module A is independent
of module B, then we can modify A without introducing any unanticipated side effects in B.
Total independence of modules of one system is not possible, but the design process should
support as much independence as possible between modules. Dependence between
modules in a software system is one of the reasons for high maintenance costs. Clearly,
proper partitioning will make the system easier to maintain by making the design easier to
understand.
Problem partitioning also aids design verification.
Problem partitioning, which is essential for solving a complex problem, leads to hierarchies in
the design. That is, the design produced by using problem partitioning can be represented as
a hierarchy of components. The relationship between the elements in this hierarchy can vary
depending on the method used. For example, the most common is the “whole-part of”
relationship. In this, the system consists of some parts; each part consists of subparts, and so
on. This relationship can be naturally represented as a hierarchical structure between various
system parts. In general, hierarchical structure makes it much easier to comprehend a
complex system. Due to this, all design methodologies aim to produce a design that has nice
hierarchical structures.

Abstraction
Abstraction is the intellectual tool that allows us to deal with concepts apart from particular
instances of those concepts. During requirements definition and design, abstraction permits
separation of the conceptual aspects of a system from the (yet to be specified)
implementation details. We can for example, specify the FIFO property of a queue or the
LIFO property of a stock without concern for the representation scheme to be used in
implementing the stack or queue. Similarly, we can specify the functional characteristics of the
routines that manipulate data structures (e.g. NEW, PUSH, POP, TOP, EMPTY) without
concern for the algorithmic details of the routines.
Abstraction is a very powerful concept that is used in all-engineering disciplines. It is a tool
that permits a designer to consider a component at an abstract level without worrying about
the details of the implementation of the component. Any component or system provides some
services to its environment. An abstraction of a component describes the external behavior of
that component without bothering with the internal details that produce the behavior.
Presumably, the abstract definition of a component is much simpler than the component itself.
Abstraction is an indispensable part of the design process and is essential for problem
partitioning. Partitioning, essentially, is the exercise of determining the components of a
system. However, these components are not isolated from each other; they interact with each
other, and the designer has to specify how a component interacts with other components. To
decide how a component interacts with other components, the designer has to know, at the
very least, the external behavior of other components. If the designer has to understand the
details of the other components to determine their external behavior, we have defeated the
purpose of partitioning-isolating a component from others. To allow the designer to
concentrate on one component at a time, abstraction of other components is used.
Abstraction is used for existing components as well as components that are being designed.
Abstraction of existing components plays an important role in the maintenance phase. To
modify a system, the first step is understanding what the system does and how. The process
of comprehending an existing system involves identifying the abstractions of sub-systems and
components from the details of their implementations. Using these abstractions, the behavior
of the entire system can be understood. This also helps determine how modifying a
component affects the system.
As we move through different levels of abstraction, we work to create procedural and data
abstractions. A procedural abstraction is a named sequence of instructions that has a specific
and limited function. An example of a procedural abstraction would be the word open for a
door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and
grasp knob, turn knob and pull door, step away from moving door, etc.).
A data abstraction is a named collection of data that describes a data object. In the context of
the procedural abstraction open, we can define a data abstraction called door. Like any data
object, the data abstraction for door would encompass a set of attributes that describe the
door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows that
the procedural abstraction open would make use of information contained in the attributes of
the data abstraction door.
Many modern programming languages provide mechanisms for creating abstract data types.
For example, the Ada package is a programming language mechanism that provides support
for both data and procedural abstraction. The original abstract data type is used as a template
or generic data structure from which other data structures can be instantiated.
Control abstraction is the third form of abstraction used in software design. Like procedural
and data abstraction, control abstraction implies a program control mechanism without
specifying internal details. An example of a control abstraction is the synchronization
semaphore used to coordinate activities in an operating system.
During the design process, abstractions are used in the reverse manner than in the process
of understanding a system. During design, the components do not exist, and in the design,
the designer specifies only the abstract specifications of the different components. The basic
goal of system design is to specify the modules in a system and their abstractions. Once the
different modules are specified, during the detailed design the designer can concentrate on
one module at a time. The task in detailed design and implementation is, essentially, to
implement the modules so that the abstract specifications of each module are satisfied.
There are two common abstraction mechanisms for software systems: functional abstraction
and data abstraction. In functional abstraction, a module is specified by the function it
performs. For example, a module to compute the log of a value can be abstractly represented
by the function log. Similarly, a module to sort an input array can be represented by the
specification of sorting. Functional abstraction is the basis of partitioning in function-oriented
approaches. That is, when the problem is being partitioned, the overall transformation
function for the system is partitioned into smaller functions that comprise the system function.
The decomposition of the system is in terms of functional modules.
The second unit for abstraction is data abstraction. Any entity in the real world provides some
services to the environment to which it belongs. Often the entities provide some fixed
predefined services. The case of data entities is similar. Certain operations are required from
a data object, depending on the object and the environment in which it is used. Data
abstraction supports this view. Data is not treated simply as objects, but is treated as objects
with some predefined operations on them. The operations defined on a data object are the
only operations that can be performed on those objects. From outside an object, the internals
of the object are hidden; only the operations on the object are visible. Data abstraction forms
the basis for object-oriented design, which is discussed in the next chapter. In using this
abstraction, a system is viewed as a set of objects providing some services. Hence, the
decomposition of the system is done with respect to the objects the system contains.