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.

------------------------------------------------------------------------------------------------