Assignment-3

Of

Software eng.

Submitted to

Lovely Professional University, Phagwara

For partial fulfillment of the required award of

MCA-M.Tech (Master in Computer Application)

Session 2009-2013

Supervised By Submitted By

Prof Mr.Ketan sood Name-Amar Singh

Faculty Class- MCA-M.Tech

Lovely Professional University Roll No. :RE3902A29

Regd. No. – 10907042

 Certificate

Assignment No.: 3 Course Code: CAP 312

Course Instructor: Mr. Ketan Sood Course Tutor:

Date of Allotment: Date of Submission: 15-April-2010

Student’s Roll No: RE3902A29 Section No.: E3902

Declaration:

I declare that this assignment is my individual work. I have not copied from any other
student’s work or from any other source except where due to acknowledgement is made
explicitly in the text, nor has any part been written for me by another person.

Student’s Signature: AMAR SINGH

Evaluator’s Comments:

__________________________________________________________________

Marks Obtained: out of______________________________________

 PART-A

Q1. Demonstrate the concept of Top down approach and bottom up approach in any
software project.

Ans: - Bottom up approach: - In a bottom-up approach the individual base elements of the
system are first specified in great detail. These elements are then linked together to form
larger subsystems, which then in turn are linked, sometimes in many levels, until a complete
top-level system is formed. This strategy often resembles a "seed" model, whereby the
beginnings are small, but eventually grow in complexity and completeness.

This bottom-up approach has one weakness. We need to use a lot of intuition to decide the
functionality that is to be provided by the module. If a system is to be built from existing
system, this approach is more suitable as it starts from some existing modules. Thus, it is
possible to build the overall layout of a product before the parts are designed.

Top down approach: - Many technologies that descended from conventional solid-state
silicon methods for fabricating microprocessors are now capable of creating features smaller
than 100 nm, falling under the definition of nanotechnology. Giant magneto resistance-based
hard drives already on the market fit this description, as do atomic layer deposition
techniques. Peter Gruenberg and Albert Fert received the Nobel Prize in Physics for their
discovery of Giant magneto resistance and contributions to the field of spintronics.

• Separating the low level work from the higher level abstractions leads to a modular
design.
• Modular design means development can be self-contained.
• Having "skeleton" code illustrates clearly how low level modules integrate.
• Fewer operations errors.
• Much less time consuming.
• Very optimized way of processing.
• Easy to maintain,
Top-down and Bottom-up Project Management: - The role the project manager plays in
the project changes. Project Management software helps him create complete delegation.
People become less dependent on the manager as a to-do generator. The project manager
turns from a taskmaster into a project leader who facilitates the team communications,
provides a creative working environment and guides the team. He becomes a visionary who
can leverage the team strengths and weaknesses and adjust project development to the
external changes.

It is up to them to choose the methods and ways to perform their tasks. The advantage of this
approach is that it empowers team members to think more creatively. They know that their
initiatives are appreciated. The team members' motivation to work and make the project a
success is increased. The planning process flows significantly faster, as it is facilitated by a
number of people. The to-do lists of all the team members are collected into the detailed
project master plan.

Schedules, budgets and results are transparent. The project manager makes all the issues clear
to avoid as many surprises as possible. The second-generation tools allow project managers
to merge the advantages of the two initial management approaches. These applications let
you combine control and collaboration, clarity of project goals and visibility of internal
organisational processes.

Q2. Identify all the components of data flow diagrams first and then implement few of
those in developing DFD for your software project.
Ans: - Data Flow Diagrams components: - There are some symbols that are used in the
drawing of data flow diagrams. Flow diagrams in general are usually designed using simple
symbols such as a rectangle, an oval or a circle depicting a processes, data stored or an
external entity, and arrows are generally used to depict the data flow from one step to
another.
A DFD usually comprises of four components. These four components can be represented by
four simple symbols. These symbols can be explained in detail as follows:
External Entity: - An external entity is a source or destination of a data flow which is
outside the area of study. Only those entities which originate or receive data are represented
on a business process diagram.

Process: - A process shows a transformation or manipulation of data flows within the

system. The symbol used is a rectangular box. This should be a simple imperative sentence
with a specific verb, for example 'maintain customer records' or 'find driver'.
Data Flow: - A data flow shows the flow of information from its source to its destination. A
data flow is represented by a line, with arrowheads showing the direction of flow. Each data
flow may be referenced by the processes or data stores at its head and tail, or by a description
of its contents.
Data Store: - A data store is a holding place for information within the system. Data stores
may be long-term files such as sales ledgers, or may be short-term accumulations.
Resource Flow: - A resource flow shows the flow of any physical material from its source to
its destination. The physical material in question should be given a meaningful name.
External Entities: - It is normal for all the information represented within a system to have
been obtained from, and/or to be passed onto, an external source or recipient. These external
entities may be duplicated on a diagram, to avoid crossing data flow lines.
Processes: - When naming processes, avoid glossing over them, without really
understanding their role. Indications that this has been done are the use of vague terms in the
descriptive title area - like 'process' or 'update'.
Data Flows: - Double headed arrows can be used on all but bottom level diagrams. In
common with most of the other symbols used, a data flow at a particular level of a diagram
may be decomposed to multiple data flows at lower levels.
Data Stores: - Each store should be given a reference letter, followed by an arbitrary
number. These reference letters are allocated as follows:
'D' - indicates a permanent computer file
'M' - indicates a manual file
'T' - indicates a transient store, one that is deleted after processing.
Data Flow Diagram for Software:

Q3. Demonstrate the concept of coupling and cohesion for any software project.
Ans– Coupling: - coupling is an inter-module concept which captures the strength of
interconnection between modules. The more tightly coupled the modules are, the more
dependent they are on each other, and the more difficult it is to understand and modify them.
Low coupling is desirable for making the system more understandable and modifiable.
Content coupling (high): - Content coupling is when one module modifies or relies on the
internal workings of another module. Therefore changing the way the second module
produces data will lead to changing the dependent module.
Common coupling: - Common coupling is when two modules share the same global data
changing the shared resource implies changing all the modules using it.
External coupling: - External coupling occurs when two modules share an externally
imposed data format, communication protocol, or device interface.
Control coupling: - Control coupling is one module controlling the flow of another, by
passing it information on what to do.
Stamp coupling (Data-structured coupling): - Stamp coupling is when modules share a
composite data structure and use only a part of it, possibly a different part. This may lead to
changing the way a module reads a record because a field, which the module doesn't need,
has been modified.
Data coupling: - Data coupling is when modules share data through, for example,
parameters. Each datum is an elementary piece, and these are the only data shared.
Message coupling (low): - This is the loosest type of coupling. Modules are not dependent
on each other instead they use a public interface to exchange parameter-less messages.
No coupling: - Modules do not communicate at all with one another

For Example: - if a module has only a single input and output data parameter

If a module has 5 input and output data parameters, an equal number of control parameters,
and accesses 10 items of global data, with a fan-in of 3 and a fan-out of 4,

Cohesion: - Cohesion is a measure of how strongly-related and focused the various

responsibilities of a software module are. Cohesion is an ordinal type of measurement and is
usually expressed as "high cohesion" or "low cohesion" when being discussed. Modules with
high cohesion tend to be preferable because high cohesion is associated with several
desirable traits of software including robustness, reliability, reusability, and understand
ability whereas low cohesion is associated with undesirable traits such as being difficult to
maintain, difficult to test, difficult to reuse, and even difficult to understand.
Logical cohesion: - Logical cohesion is when parts of a module are grouped because they
logically are categorised to do the same thing, even if they are different by nature
Temporal cohesion: - Temporal cohesion is when parts of a module are grouped by when
they are processed - the parts are processed at a particular time in program execution.
Procedural cohesion: - Procedural cohesion is when parts of a module are grouped because
they always follow a certain sequence of execution.
Communicational cohesion: - Communicational cohesion is when parts of a module are
grouped because they operate on the same data.
Sequential cohesion: - Sequential cohesion is when parts of a module are grouped because
the output from one part is the input to another part like an assembly line.

PART-B
Q1. As a debugger how will you identify different errors in software project? Suggest
some techniques to avoid errors during coding.
Ans: - Debugger: - Everyone who has used a debugger knows what breakpoints are, but
when combined with other debugger features breakpoints become much more powerful tools.
In this article, I will talk about how to combine these features and give examples of how such
combinations can be used to solve some real world problems.
Errors in software project:
Controlling Multi-Thread Systems with Breakpoints: - It is even more likely that
problems will be difficult to reproduce when dealing with multi-thread or multi-process
systems. For these problems you can control the timing of program flow with scripted
breakpoints to force things to happen in a specific order.
Call Stack Breakpoints: - Moving beyond printf debugging, there are a number of other
techniques that are possible when combining different debugger features. Related to printf
breakpoints are "call stack breakpoints". In this case, instead of just printing out a particular
variable when a breakpoint is hit, we ask the debugger to dump out a full call stack.
Breakpoint Recursion Detection: - At this point, I could have added code to the function to
detect when it was called recursively, in order to create a place to set a breakpoint. However,
it takes several minutes to rebuild and link the application that I was debugging, so instead, I
used the debugger to perform the recursion detection.
Forcing Program Flow with Breakpoints: - Sometimes you might have a suspicion about
what is going wrong, but you just can't get the program to take the dubious code path. When
you find yourself in this situation, you can often use the debugger to force the code path to be
taken.
Printf Breakpoints: - In spite of these issues, there are good reasons that printf is so
commonly used: It's simple, it works most of the time, and most importantly, developers are
used to it. So the first use of breakpoints will be to replicate the familiar approach of printf,
but from within the debugger. This gets you most of the advantages of printf with much more
flexibility.
What you Need in a Debugger
* The debugger has to be able to set and remove breakpoints when executing commands
when a breakpoint is hit.
* The debugger has to be able to run your program with minimal to no intrusiveness when
breakpoints are not being hit.
* The debugger has to support setting hardware write breakpoints.
* The debugger needs to provide a simple way to move the program counter from one line
within a function to another.
* The debugger needs to be able to execute command line procedure calls from within a
breakpoint.
* The debugger needs to be able to debug multiple threads at the same time and be able to set
and remove breakpoints on any thread from any other thread.

Q2. Create algorithm design document for any software project.

Ans – Algorithm design of software project: - The algorithm design of software project is
following steps:
Design considerations: - There are many aspects to consider in the design of a piece of
software. The importance of each should reflect the goals the software is trying to achieve.
Some of these aspects are:

• Compatibility - The software is able to operate with other products that are designed
for interoperability with another product. For example, a piece of software may be
backward-compatible with an older version of itself.
• Extensibility - New capabilities can be added to the software without major changes
to the underlying architecture.
• Fault-tolerance - The software is resistant to and able to recover from component
failure.
• Maintainability - The software can be restored to a specified condition within a
specified period of time. For example, antivirus software may include the ability to
periodically receive virus definition updates in order to maintain the software's
effectiveness.
• Modularity - the resulting software comprises well defined, independent
components. That leads to better maintainability. The components could be then
implemented and tested in isolation before being integrated to form a desired software
system. This allows division of work in a software development project.
• Packaging - Printed material such as the box and manuals should match the style
designated for the target market and should enhance usability. All compatibility
information should be visible on the outside of the package. All components required
for use should be included in the package or specified as a requirement on the outside
of the package.
• Reliability - The software is able to perform a required function under stated
conditions for a specified period of time.
 • Reusability - the modular components designed should capture the essence of the
functionality expected out of them and no more or less. This single-minded purpose
renders the components reusable wherever there are similar needs in other designs.
• Robustness - The software is able to operate under stress or tolerate unpredictable or
invalid input. For example, it can be designed with a resilience to low memory
conditions.
• Security - The software is able to withstand hostile acts and influences.
• Usability - The software user interface must be usable for its target user/audience.
Default values for the parameters must be chosen so that they are a good choice for
the majority of the users. In many cases, online help should be included and also
carefully designed.

Modelling language: - A modelling language is any artificial language that can be used to
express information or knowledge or systems in a structure that is defined by a consistent set
of rules. The rules are used for interpretation of the meaning of components in the structure.
A modelling language can be graphical or textual. Examples of graphical modelling
languages for software design are:

• Business Process Modeling Notation (BPMN) is an example of a Process Modeling

language.
• Extended Enterprise Modeling Language (EEML) is commonly used for business
process modeling across a number of layers.
• Flowchart is a schematic representation of an algorithm or a stepwise process,
• Fundamental Modeling Concepts (FMC) modeling language for software-intensive
systems.
• Jackson Structured Programming (JSP) is a method for structured programming based
on correspondences between data stream structure and program structure

Q3. How will you flow particular information in your company when number of
Persons are working on different responsibilities and levels?

Ans - Different Responsibilities: - Different Responsibilities are-

Step 1: the basics: - The first step is dreaming out loud. Make a couple of drafts of dreamed
of solutions. Do not restrict yourself, dream out loud. Quickly draft some structures with
different roles, levels, etc. The biggest downfall in this step is immediately starting to limit
you and discussing why it is not feasible.

Step 2: reality check: - The Pareto principle at work for you. 80% of your dreamed change
is already known to you. It will cost you 20% of energy and time to get it out in the open.
Discovering the last 20% will on the other hand cost you 80% of your time and energy. Most
people think of these 20% when they think about change.

Step 3: choose the best solution for now: - Take the results of step one and two and start
doodling. Doodling you go back and forth between your dreams and the facts of reality. A
couple of dream scenarios will not make it to the final selection based on what is possible.
Before you throw them out. Draw new solutions. Nothing is final here but you are looking
for an 80% candidate that you can put to a test. Done doodling? Make two more!
Step 4: make your test: - Every complex organization needs a set of roles and behaviours
that are essential to govern it. For example, someone, either alone or in partnership with other
senior executives, must set strategic vision and direction. Below the article you find 11
specific roles that together constitute both the strategic and operational responsibilities of
corporate leadership.

Step 5: put your selected structure to the test: - This step is especially interesting to do
with all the people involved. It starts the dialog between everybody and creates a lot of
clarity. For every role and the responsibilities therein score which of your designed roles is
taking the lead and which role will be the backup in your organization.

Step 6: evaluate the outcomes and make changes: - Some rules to look at in this step:
- To be effectively organized you want to share the workload among the team
- You want logical groups of responsibilities to minimize the overhead and create maximal
clarity
- You probably want healthy check and balances. Some roles need conflicting interest to
create a balanced and optimal output for your organization.

Step 7: The famous gap analysis: - Until now you designed a structure and defined roles
and responsibilities. The next thing is to put the present situation next to this desired
outcome. You will find small and big gaps. There are many questions to be answered in this
step. An aspect you should address before but becomes more pressing in this step is the
questions of the people involved and their sense of security.

Step 8: do it: - Execution is everything! The plan may be right but if the execution stinks
nothing good will come forth! In this step the people that stay need to take on their new roles
and responsibilities. New people may get on board and take on their roles. This phase will
ask al lot from the people involved. They will need to come to an understanding of their
intrinsic reason to work for the company and if their personal believes and values fit their
role and responsibility.

MANAGEMENT LEVELS: - Managers are organizational members who are responsible

for the work performance of other organizational members. Managers have formal authority
to use organizational resources and to make decisions. In organizations, there are typically
three levels of management: top-level, middle-level, and first-level.

TOP-LEVEL MANAGERS: - Top-level managers, or top managers, are also called senior
management or executives. These individuals are at the top one or two levels in an
organization, and hold titles such as: Chief Executive Officer, Chief Financial Officer, Chief
Operational Officer, Chief Information Officer, and Chairperson of the Board, President,
Vice president, and corporate head. Top managers in most organizations have a great deal of
managerial experience and have moved up through the ranks of management within the
company or in another firm.

MIDDLE-LEVEL MANAGERS: - Middle-level managers, or middle managers, are those

in the levels below top managers. Middle managers' job titles include: General Manager,
Plant manager, Regional manager, and Divisional manager. Middle-level managers are
responsible for carrying out the goals set by top management. They do so by setting goals for
their departments and other business units.
FIRST-LEVEL MANAGERS: -First-level managers are also called first-line managers or
supervisors. These managers have job titles such as: Office manager, Shift supervisor,
Department manager, Foreperson, Crew leader, Store manager. There are first-line managers
in every work unit in the organization. Although first-level managers typically do not set
goals for the organization, they have a very strong influence on the company.