ASSIGNMENT OF
ADVANCED SOFTWARE ENGINEERING
Question No. 1 What do you mean by
product life cycle? Explain the seven stages of product life cycle?
Product Life
Cycle:-
In the
previous section, we discussed the frequently used software engineering terminologies.
You learnt the difference between a product and a process. A series of steps is
required to manufacture a product. Let us in this section, the different stages
in the product life cycle. The product developed should satisfy the customer. The
series of steps involved in developing the product is called the product life
cycle. The seven stages in a product life cycle are:
A set
of deliverables that is delivered to a customer is called a product. It
includes documentation, manuals, source code, etc. We can define a process as
the set of activities that are followed for producing a product. Process is the
way for producing software. The process should be efficient to get good quality
products.
Let us
now discuss in detail the seven stages of the product life cycle.
1. Analysis stage:-
In this
stage, the development team analyzes the problem in an existing application or
finds new ideas for an application. After identifying the idea, the development
team needs to determine the scope of the problem. After identifying the scope,
the development team can easily identify the essential components necessary for
the product development. The important thing for software development is the
system requirement. The system requirement differs based on the software
product. The development team should carefully analyze the requirements needed
for the product development.
2. Design stage:-
This is an important stage in the product life
cycle. In this stage, the development team designs the individual components
and creates the blue prints. The analysis done in the analysis stage helps to
create the design documents. Designs such as database design, functional
specification design, and document design take place in this stage. The design
needs to be done carefully because the development stage depends upon the
design created during the design stage. If the design prepared is well
structured, it reduces the time taken in the upcoming stages of the product
life cycle.
3.
Development stage:-
In this
stage, the actual development of the product takes place according to the blue
print created in the design stage. The team members start writing code for the
product. The product is divided into different modules and each member is
allotted a separate module to develop the product. The code is written based on
the chosen technology. Generation of code takes place after the code is
developed. The code is executed after it is generated.
4. Testing stage:-
It is
essential to test each and every product before it is launched in the market.
The quality assurance cannot be given to a product if it is not tested. We must
test the developed product to ensure that it meets the specifications stated in
the design stage. In this stage, the developed product is tested and reports
are prepared. The report describes the errors in the developed products. There
are different methods for testing the developed product. Unit testing and
system testing methods are used for testing the product. After this stage, the
life cycle again moves to the development stage to correct the errors
identified in this stage. After correcting the errors, the product is again
tested. This process continues till the product is found to be error-free.
There are some tools available to test the developed product. We can use these
tools to test a product and identify the defects. These tools are used to make
the testing easy and to get an error-free product. The test scenarios are
written by the testers to check the testing needs of software application. The
test scenario drives the test cases which are related to the requirements and
designs. Depending upon the type of requirement and design, the test scenarios
are addressed as functional and structural. The test scenario should be
feasible, clear, complete, and cover all requirements. The test scenario and
the test case should be prioritized as per the requirements. After completing
product testing, versions of completed product are supplied to the clients for
testing onsite. The first version is the alpha release and the corrected
version is the beta release. Usually the final version is the beta release.
5.
Implementation stage:-
This is
known as First Customer Ship (FCS) in software industry. After the development
and testing stage the product moves to the implementation stage. In this stage
the product is taken to the end users.
6.
Maintenance stage:-
The software maintenance stage is the longest
stage in the software life cycle. This stage is distinguished in terms of
costs. About 90% of the total life cycle cost of the software is consumed in
the maintenance stage. The software maintenance activity is classified into
four types. They are perfective, adaptive, corrective and preventive. The
maintenance of the software is not performed by the person who creates the
product. In this stage, the problems raised by the customers after releasing
the product are rectified. The testing team tests the product again and
rectifies the errors that are raised by the customers.
7. End-of-life stage/Retirement stage:-
The
final stage of the life cycle is the retirement stage. This stage is reached after
many years of service. In this stage, the product is replaced with a newer
version that has enhanced features. Thus, the old product’s life cycle comes to
an end. This is the end stage for the old product. There are many instances in
which the current version is replaced with new version. The true retirement
occurs when a product has outgrown its usefulness. The functionality of the
product is removed from the computer. Now that you are familiar with the
product life cycle, let us next discuss the project life cycle models. A
project life cycle can be a subset of a product life cycle. This means that a
product life cycle can have many project life cycles.
Question No. 2
List any ten major principles of agile software?
Agile
Software:-
Although
different developers prefer different flavors of agile, they realized that all
flavors have some common principles. The agile Manifesto was formulated by 17
software developers who gathered in February 2001 in the Wasatch Mountains of
Utah. It was formulated to find a common baseline for their perceptions of
software development process and to develop the common elements previously
implemented in various software organizations. The Agile Manifesto presents an
alternative strategy to the software development process that had been
implemented during the past 40 years, starting from the early phases of the
development of complex software systems. Different agile methods apply the
Agile Manifesto and some of them are:
A. Scrum
B. DSDM
C. Extreme Programming
D. Crystal
E. Adaptive Software Development
F. Feature-Driven Development
List any ten
major principles of agile software
1. Satisfying the customers with
early and continuous delivery of valuable software is agile software’s major
priority.
2. Welcoming varying requirements,
even during the later phases of development. Agile processes also support
change for the customer’s competitive benefit.
3. Delivering working software
often, with a shorter timescale is preferred.
4. Involving business people and
developers in development of agile process and making them work together every day
during the project.
5. Developing projects around
motivated individuals and also providing those individuals the environment and
the support they require, and trusting them to get the work done.
6. Considering face-to-face
conversation as the most proficient and useful way of conveying information to
a development team.
7. Considering working software as
the major measure of progress.
8. Supporting sustainable growth by
ensuring that the sponsors, developers, and customers maintain a steady pace
indefinitely.
9. Providing constant attention to
technical excellence and improving agility with good design.
10. Simplifying, which is the art of
maximizing the amount of work performed, is very crucial.
Question No. 3 List the four developer
practices of XP. Explain briefly about Adopt test-driven development?
Developer
Practices:-
Developers
must work together regardless of the size of the project. If the team is able
to work smoothly, then they can deliver high quality software. As everyone in
the team contributes to the project, XP dedicates several practices to improve
the teamwork. These practices strengthen the good programming practices of the
team. They also help to nurture and guide the less experienced developers of
the team. Thus, XP developer practices help to keep everyone in the team on
track.
1. Adopt test-driven development
2. Practice pair programming
3. Adopt collective ownership
4. Integrate continually
Adopt
test-driven development:-
The
main reason for adopting test-driven development practice is to prove that the
code developed works based on the requirement. XP emphasizes the need for
testing every code as and when it is developed. You must test the code to check
if the code actually does what it is intended to do and if anything can make
the code to behave erratically. Usually traditional testing is carried out by
writing test cases to check the conditions under which the software fails. But
XP also writes test cases to find out if the software passes the test. In XP,
the development of a feature is said to be finished only when it passes the
test. Therefore, test your code or feature whenever you get an opportunity to
run a test. This gives the developer the confidence about the code. Also, you
must run a test before and after refactoring your code. You must remember that
finding a bug in few lines of code is easy, but finding the bug in a code with
hundreds of lines is difficult. Many automated testing tools or frameworks are
available for testing. Using a good testing framework helps to save lot of time
and resources. It also gives an accurate feedback about the status of the
project any time. Manual testing may fail to identify or overlook certain bugs,
but it does not happen in automated testing. A good test must try to explore
one issue at a time. When a code fails the test, you must have sufficient
information to track the test to identify and debug the software. Therefore,
you must use simple tests as they enable easy debugging when compared to
complex tests. Usually tests are of two types:
Unit
test - This test is carried out to find out the behavior of the individual
pieces or functions of the software.
Acceptance
test - This test is carried out to verify that the software features match the
business requirements and expectations of the customer.
Every
unique piece of code requires its own test case. The test case probes the
limits of expected and unexpected use of the codes. It also serves as a guide
for any future changes. Usually a well written unit test also tells you how to
use the code. The acceptance test case is written based on the customer’s
requirements. You must work with the customer to write automated acceptance
tests to prove to the customer that all the requirements are met successfully.
Only when the software passes the acceptance test, the development is complete.
Test-driven development supports refactoring to improve the software
efficiency. It helps developers to ensure that the system is kept in good
condition during every release. It also serves as a benchmark for future
development. Any test-driven development method requires positive peer pressure
to help developers to overcome the initial setbacks of test-driven development
method and continue testing even if it seems difficult. At the same time, it is
also essential to clearly communicate with the customer and obtain the test
cases from the customer for acceptance tests.
Question No. 4
What is a story card? Briefly explain the various steps in creating a story
card.
Story Card:-
The
customers convey their requirements of a desired feature as a story card. A
story card informs the developer the customer’s specification. Based on the
inputs the customer provides, the developers estimate the schedule to develop
the required software (or software feature). As developers also contribute in
iteration planning, we can consider it developer driven. The customer has to
prepare for the iteration planning session by giving more details about the
stories. This can be done in the following ways:
1. The customer can briefly explain the story.
As this is simple and verbal, it is effective.
2. The
customer can present a written description of the story details. This can be of
few pages, and it mainly tries to corroborate all the important aspect of the
story.
3. The
customer can provide an acceptance test for the story.
The
discussion between the customer and developer results in the production of task
cards. A task is characterized by the total effort it needs i.e., actual number
of person days required to implement the story card. Usually a task is assigned
to one team member or pair of developers for developing the code.
The
business changes can affect the pending stories as the project progresses. The
customer re-evaluates their business requirements when necessary. This affects
the tasks as when the stories change, even the tasks also change. Therefore,
you have to evaluate the tasks that may have changed after planning the
iteration. Usually stories are written along with acceptance tests to check
whether the story has been implemented correctly. The acceptance test is
written on a card called index card. Each story will have one acceptance test,
but sometime one acceptance test will be written for more than one story or one
story may have more than one acceptance test. However, the story and its
respective acceptance test have to be implemented in the same iteration. The
developer estimates the time to complete each story. This is done by assigning
each story a number of story points or milestones. Therefore, every iteration
has number of story points that are implemented one after the other through the
course of the iteration. These story points determine the project velocity. At
the end of each iteration, the customer and the developer have to identify the
number of story points actually implemented.
Question No. 5
Explain XP prerequisites.
1. Team agreement:-
The
team’s agreement to use XP is as important as management support. If team
members do not want to use XP, it’s not likely to work. XP assumes that each
team member’s willingness to adopt it. It is not a good practice to force the
process on somebody who is resisting it.
2. A collocated team:-
XP
relies on high-frequency and high-speed communication for most of its practices.
To achieve that communication, the team members must sit together in the same
room. (Source: Reproduced from Schuh, P
.(2003). Integrating Agile Development in the Real World, 1st ed. USA: Charles
River Media, Inc. p 280) The seating arrangement of a collocated team is based
on a ’caves and commons’ approach. The objective of this approach is to provide
people access to ’commons’ where they can interact together, and ’caves’ where they
can work alone.
3. On-site
customers:-
On-site
customers are essential to the success of an XP team. They, led by the product
manager, decide which features the team will develop. These decisions impact
the value of the software. Therefore, the customer is part of the development
environment. Having an on-site customer is the best way to get immediate
feedback. When the customers are on-site they can answer queries immediately.
When both customer and developers are guided by a reflective mode of thinking,
they can improve their understanding of the software or application being
developed. For example, when after some problem is corrected, the customer and
the developers can reflect on their current understanding of the software or
application and compare it with the understanding that preceded it. XP
encourages short release cycles. Consider the problems when the customer only
sees new releases of the software every few months. If there is considerable
time in between feature releases, the customers cannot give real-time feedback
to the programming team. Months of hard work may go waste if customers change
their minds, or if the programmers do not deliver what is expected by the
customer.
4. The right
team size:-
According
to the proponents of XP, certain factors make some projects well suited for
this methodology. The first major issue is the size of the team. In general, XP
is most effective in cases where small teams, of usually two to 12 programmers,
are involved. Small teams are more flexible, and better able to adapt to
changes than 50 or 100-person programming giant teams. An XP team cannot just
have one member. It needs an even number of programmers due to the XP concept of
pair programming. To use this approach, pair the team. Each pair must share a
single computer and each person in the pair must focus on a different angle of
the problem. While one developer types and actually applies and implements the
code, the second developer must check for syntax and spelling errors. The other
developer must understand how the current module that is being developed fits
into the whole work. The two developers in the pair alternate their roles as required
and brainstorm on the best approach a particular problem. Teams with less than
four programmers may not have the intellectual diversity needed. They will also
have difficulty using pair programming, which is a significant support
mechanism in XP. However, large teams face challenges of coordination. Although
experienced teams can handle those challenges efficiently, a new XP team may
experience difficulties in the beginning.
Use all XP
practices:-
XP
utilizes all the resources of the project efficiently. It also ensures that every
practice directly contributes to the development of valuable software. The
recommended practices of XP are as follows:
I. A brand-new codebase
II. Strong design skills
III. A language that is easy to refactor
IV. An experienced programmer-coach
V. A friendly and cohesive team
Question No. 6
Explain in detail about version control tools?
Version
control:-
Version
control tools are essential building blocks of any software development
projects. Concurrent Version System (CVS) is the most popular version control
system. CVS keeps a master copy of each file on a server known as repository.
The repository has a history of all the files. You can view history of changes,
recover previous revisions of files and mark particular revisions with tag
names. The files can be maintained in a predictable and repeatable way by using
tools like CVS. The copy of the entire code is available for the programmers on
their computer and they can make changes without affecting other programmers.
The programmers commit the modified files to the CVS repository after the
current task is completed. The revised files are visible to other programmers
and they can choose to update to the new versions when they are ready. Working
in small steps is a necessity because XP requires pair programming. If you work
on a task that takes several days to complete, then you cannot switch your
programming partners several times. A key to XP success is completing a task
within a few hours by breaking the project into smaller tasks. Working in small
steps also helps when using CVS because your personal workspace is always
synchronized with the repository. Multiple programmers may work on a team on
the same files concurrently with CVS. So you have to merge changes and resolve
conflicts before committing your modified code to repository. The conflicts can
be minimized by performing frequent updates. The likelihood of conflict
increases with work done by other team members if the programmer does not get
the code for days and weeks at a time. CVS allows concurrent edits to the same files
but other version control programs force programmers to lock files before
making changes. While exclusive locking seems safer than concurrent editing, it
can impede development if other team members are unable to make changes. When working
with locking version control tools, working in small steps is the best way to
avoid problems. The likelihood of lock connection is reduced if each programmer
locks only few files at a time.
------------------------------------------------------------------------------------------------
