Beruflich Dokumente
Kultur Dokumente
Assignment – I
Of
Software Project
Management
Ans.:-
MY CURRENT ROLE
Do the Job Well
First and foremost a programmer must do his or her current job well to be
considered for a promotion. After all, how can we be promoted to a new job if
we haven’t demonstrated competence in the current one? This includes
following all company and department SOPs, guidelines and other policies. I
wrote a paper called “Writing Code that Lasts” for SUGI 2004 1 that contains
many tips on how to excel in the technical side of our job, and I will not go into
those details again here.
We should get a copy of our job description plus look through annual reviews to
make sure we’re meeting or exceeding expectations. These will give us some
ideas on where to focus our energy for improvement in our current position.
Keep in mind that we can’t break away from our current job if nobody else can
do it. To avoid this situation, we need to write clear code and provide
appropriate documentation so that others can easily work with it.
Job Research
After completing the personal research to figure out what we want to do, we can
then tackle finding a job that has these traits. If we’re interested in finding
another position within our current company, we have many resources available
to us. Often there are job descriptions available via a company intranet, but if
not our manager and/or the HR department should be able to get these for us.
We can consider positions within and outside our own department, and should
think about not just the next job, but the entire direction of our career and the
various jobs that could help get us there: in other words, a career path.
Once we find positions of interest, we should then try to learn more about them.
A job description doesn’t usually tell the whole story. Find some people
currently in those positions, talk to them about what they really do, and see out
what they like/don’t like about the job.
It might be that our career objectives aren’t a good match for our current
company. Some examples include when:
• We’ve been working with clinical trials data but have a burning desire to
work in the financial industry
• They expect no openings in the area we want to move into
• We want to move into or out of contracting/consulting
Q. 2.
Ans.:-
Many systems and software engineering organizations use the following phases
Within each of these four phases, they define clear objectives and follow a
development lifecycle that includes requirements, analysis and design, code and
unit test, subsystem integration, implementation, testing; and other disciplines,
such as configuration management.
The outcome of each phase is a tested product of known maturity. In their
implementation, however, these four phases allow for many variations. For
example, take the Product Development Phase. What is the expected duration of
this phase? Weeks, months, quarters (three months), years, tens of years? Also,
does the result of the Proof-of-Concept Phase form part of the final product, or
is it to be scrapped and redeveloped? Do all of the artifacts mature over time, or
is there an expectation that they have been "signed off" on, never to be updated
again?
Now that we've looked at a common form of phased development, let's look at
phased development as defined by the Rational Unified Process® (RUP®),
which we will use as the basis of our methodology.
The RUP defines four phases for iterative development (see Figure 2). Each
phase provides the team with a specific focus to support the continuous and
controlled refinement of the requirements, architecture, design, and code. These
phases are:
The RUP advocates two levels of granularity for planning: a coarse grain for
the four phases of the project (outlined in the Software Development Plan), and
within each phase, a fine grain called an iteration (detailed in the Iteration
Plan).
Within any phase, there will typically be one or more iterations of a
manageable duration (e.g., one week to many months), depending on the size of
the project.
Every iteration is planned in sufficient detail to ensure that all team members
have a clear and unambiguous understanding of the iteration's objectives, scope,
and evaluation criteria. This is so that only essential activities required to meet
the objectives and evaluation criteria are performed during the iteration. See the
below for details about other terms, RUP activities, and artifacts referred to in
this article.
Challenges of Iterative Development
Q. 3.
Ans.:-
In it, I will argue that many issues related to software development processes,
and mainly to problems associated with such processes, can be explained by the
fact that software is an intangible product. I will suggest that if we adopt this
perspective when addressing software development processes, we might arrive
at different kinds of insights. Googling the expression "problems with software
development” results in more or less the following items: requirement
complexity, customers' inability to know all the requirements in advance,
changes in requirements, difficulties in managing frequent changes, process
bureaucracy, difficulties in estimating development times, budget overrun, and
the application of a wrong process for the development process.
A fast glance is sufficient to reveal that all these problems are connected to
people (mainly customers and team members) and that their origin is rooted in
human aspects (primarily cognitive and social) rather than in technological
ones. The outcomes of these problems are well known. Such outcomes include,
for example, buggy software products and customers who are unsatisfied with
the products they receive (some estimations indicate that about 75% of
customers are not pleased with the product they requested). The first outcome
mentioned clearly derives from a cognitive factor: testing software products is
not an easy or trivial task; the second outcome derives from a social issue,
namely the communication channels between customer and developers.
So far, we have seen how software intangibility influences mainly the social
aspect of software development. In the next paragraphs I will highlight the way
in which the fact that an intangible entity – software – is executed on a
computer further influences the entire process of software development, this
time mainly from a cognitive perspective.
Q. 4.
Ans.:-
Selecting suppliers
Styles also vary noticeably between the public and private sector:
Start by defining what you need. Try to limit this to the genuine business
requirements. Do not make assumptions about the solution nor add in
unnecessary detail. To do so would restrict the vendors' ability to propose the
best overall solution to meet your needs.
After a reasonable period of time the vendors submit the proposals to you for
evaluation. Before they arrive you should have taken the time to define how you
will assess the responses. Develop a balanced view of the relative importance of
various requirements. Just because you asked 100 questions about accounting
and only 10 about the electronic storefront does not mean the accounting issues
outweigh the customer perspective.
You might still approach several vendors and request information, prices etc.
The key difference is that you collect the information you need, then make a
decision. You do not ask them to submit formal bids against a specially
prepared RFQ document.
Following your decision in principle, typically you would still enter into
negotiations with the vendor to ensure you get a good deal that meets your
needs and avoids any contractual pitfalls.
The great advantage would be the time saving. Preparing a formal RFP can
often take several weeks. It will take a further period of weeks for it to be
received by the vendors, studied, queried, and responded to. On receipt of the
vendors' proposals you might then spend weeks reading, querying, investigating
and evaluating the detail.
This style of procurement is also the typical way you would hire individuals as
sub-contractors - for example contract programmers. You would evaluate the
individuals' career histories and capabilities, interview them, then attempt to
come to mutually agreed terms with those that you consider the most
appropriate.
Where the contract concerns a commodity item, you might pay even less
attention to the choice of item and vendor. If you need a projector, you might
simply find the nearest supplier and buy or hire one.
In some cases, significant contracts can be handled in this way, provided the
content is subject to pre-existing, approved purchase lists. For example, you
might be able to buy 100 PCs directly from an approved supplier or you might
be able to hire consultants through a framework contract.
Even in such cases, you may need to consider the detail of the contractual
relationship. Unless the transaction is a simple consumer purchase, you will
need to check the small print for warranties, terms and conditions etc.
Q. 5.
Fixing and finding a software after delivery costs 100 times more than
finding & fixing a problem in early design hours. Discuss
Ans.:-
When an old idea is a good idea that improves to become a better idea, we
should all want to benefit from that evolution.Software Inspection was a good
idea when started in 1972. Inspections havecontinued to provide a quick return
on investment and perhaps one of thequickest for all the methods and processes
available to the software practitioner.
The following excerpts are from my recent book, High Quality Low Cost
Software Inspections, and are included here with the permission of my
publisher. [RAD02] While I cannot in this brief article address all aspects of the
Software Inspections evolution since 1972, I believe you will find excerpts
below that may stimulate you to further exploit Software Inspections. And if
you are one of those who have cast away Inspections for whatever reason, I
sincerely anticipate that you will try them again to your advantage.
When I am asked which Key Process Area in the SEI’s Capability maturity
Model (SW-CMM I think gives the most value or which should be the highest
priority, I always respond with Inspections (Peer Reviews in the SW-CMM). I
believed this to be true in the 1980’s and I still believe it today. With an honest
effort given to Inspections, we can open the eyes of management for more rapid
process improvement. Inspections never fail to deliver as promised, or prove to
be too difficult, when the preconditions are satisfied. We know how to make
Inspections successful.
If Inspections provide significant benefit, why has adoption been so slow? Why
is not all of the software community using the method? The publicly published
data twenty-four years ago clearly demonstrated their effectiveness, and recent
reports continue to demonstrate their effectiveness. Why have Inspections not
taken a firmer root and achieved wider use?
The reasons for this vary. I believe this is partially due to views that Inspections
can only be done one way. This book will eliminate at least some of this
misunderstanding. Another reason for the resistance to Inspections is the view
that they are not easy to do well. There are factors, including social and
psychological, that we must consider. Management often views Inspections as
an added cost, when in fact Inspections will reduce costs during a project. We
will see throughout this book how Inspections save both cost and time.
Since the inception of Inspections, with the advent of each new development
tool or language, the providers and users seem to believe that Inspections do not
add value or are less necessary. This is clearly not true, since programmers still
make defects with these tools and languages. However there often is little
documentation as to how well Inspections work in these new environments, so a
false belief that Inspections do not apply may be propagated by myth. We will
see later in the book that Inspections do apply in these development
environments also.
Because of these and other factors, shortcuts in the Inspection process have
been taken without any proof that the change is an improvement. Some of these
homegrown changes cause the Inspection process to be less effective. In turn
the value of what was defined as the Inspection process is diminished. Thus
failure becomes a self-proving "fact."
How many times have you been convinced, absolutely convinced, that you had
either written a defect-free program or had "tested out" all of the defects only to
sadly discover that there was yet another "bug"? One has to wonder how we as
programmers have been able to repeatedly survive this cruel onslaught to our
egos. I am not talking about the slovenly programmer who in some instances
seems to develop as many defects as lines of code (LOC) in a program or
paragraphs in a document, or about the programmers who have found
themselves in a schedule crunch and don’t have enough time to develop their
best work. Rather, I am talking about that qualified programmer (you and I are
probably good examples; well, at least you), who does have sufficient time to
produce a defect-free piece of work. Yet, after the program is delivered to test
or to the user, defect fixes have to be applied to the work product. I am not
going to try to come to terms here with why this may happen, for there can be
many systemic reasons. Let it be known for now that good programmers do
indeed make defects, and if this is true for good programmers then it must
follow for all others in the population of programmers. All programmers can
and do want to learn from their injected defects. We will see later in the book
how both Inspections and Defect Prevention are natural combined processes for
programmers to use, when they are adapted for effective success.
Every organization or company hires the best people. At least that is what we
hear. One has to wonder where the worst people go. Some of them exist in
every organization. Most cultures will not easily accept the reality of a natural
distribution of capability and talent. It seems to be almost a taboo subject.
Nonetheless it exists in every organization. What we should want to do, and
what the SW-CMM enables, is to achieve a higher maturity and improved
capability in software processes for all people in an organization.
Q. 6.
Ans.:-
Planning
Once the general requirements are gathered from the client, an analysis of the
scope of the development should be determined and clearly stated. This is often
called a scope document.
Deployment starts after the code is appropriately tested, is approved for release
and sold or otherwise distributed into a production environment.
Bug Tracking System tools are often deployed at this stage of the process to
allow development teams to interface with customer/field teams testing the
software to identify any real or perceived issues. These software tools, both
open source and commercially licensed, provide a customizable process to
acquire, review, acknowledge, and respond to reported issues. (software
maintenance)
Software Development Models
Several models exist to streamline the development process. Each one has its
pros and cons, and it's up to the development team to adopt the most appropriate
one for the project. Sometimes a combination of the models may be more
suitable.
Waterfall Model
The waterfall model shows a process, where developers are to follow these
phases in order:
In a strict Waterfall model, after each phase is finished, it proceeds to the next
one. Reviews may occur before moving to the next phase which allows for the
possibility of changes (which may involve a formal change control process).
Reviews may also be employed to ensure that the phase is indeed complete; the
phase completion criteria are often referred to as a "gate" that the project must
pass through to move to the next phase. Waterfall discourages revisiting and
revising any prior phase once it's complete. This "inflexibility" in a pure
Waterfall model has been a source of criticism by other more "flexible" models.
Spiral Model
1. spiral model emphasize risk analysis, but require customers to accept and
believe that much of this analysis, and make the relevant response is not
easy, therefore, this model is often adapted to large-scale internal
software development.
2. If the implementation of risk analysis will greatly affect the profits of the
project, then risk analysis is meaningless, therefore, spiral model is only
suitable for large-scale software projects.
3. Good software developers should look for possible risks, an accurate
analysis of risk, otherwise it will lead to greater risk.