BT0092 – Software Project Management – 4 Credits

ROLL NO :-

NAME :- LAKHWINDER SINGH

LC CODE:-01687

Ques.1 Explain black box and white box testing techniques.

Black-box: This testing methodology looks at what are the available inputs for an application and what the expected outputs are that should result from each input. It is not concerned with the inner workings of the application, the process that the application undertakes to achieve a particular output or any other internal aspect of the application that may be involved in the transformation of an input into an output. Most black-box testing tools employ either coordinate based interaction with the applications graphical user interface (GUI) or image recognition. An example of a black-box system would be a search engine. You enter text that you want to search for in the search bar, press “Search” and results are returned to you. In such a case, you do not know or see the specific process that is being employed to obtain your search results, you simply see that you provide an input – a search term – and you receive an output – your search results.

Advantages of Black-box testing- Since tester does not have to focus on the inner working of an application, creating test cases is easier.- Test case development is faster as tester need not to spend time on identifying the inner processes; his only focus is on the various paths that a user may take through GUI.- It is simple to use as it focuses only on valid and invalid inputs and ensures that correct outputs are obtained.

Drawbacks of Black-box testingconstantly changing GUI makes script maintenance difficult as the input may also be changing. Interacting with GUI may result in making the test script fragile and it may not properly execute consistently.

White-box: This testing methodology looks under the covers and into the subsystem of an application. Whereas black-box testing concerns itself exclusively with the inputs and outputs of an application, white box testing enables you to see what is happening inside the application. White box testing provides a degree of sophistication that is not available with black-box testing as the tester is able to refer to and interact with the objects that comprise an application rather than only having access to the user interface. An example of a white-box system would be in-circuit testing where someone is looking at the interconnections between each component and verifying that each internal connection is working properly. Another example from a different field might be an auto-mechanic who looks at the inner-workings of a car to ensure that all of the individual parts are working correctly to ensure the car drives properly.

Advantages of White-box testing- Since the focus is on the inner working the tester can identify objects pro grammatically. This can be useful when the GUI is frequently changing.- It can improve stability and re usability of test cases provided the object of an application remains the same.- By testing each path completely it is possible for a tester to achieve thoroughness.

Drawbacks of White-box testingDeveloping test cases for white-box testing involves high degree of complexity therefore it requires highly

skilled people to develop the test cases. Although to a great extent fragility is overcome in white-box testing BUT change in the objects name may lead to breaking of the test script.

The main difference between black-box and white box testing is the areas on which they choose to focus. In simplest terms, black-box testing is focused on results. If an action is taken and it produces the desired result then the process that was actually used to achieve that outcome is irrelevant. White box testing, on the other hand, is concerned with the details. It focuses on the internal workings of a system and only when all avenues have been tested and the sum of an application’s parts can be shown to be contributing to the whole is testing complete

Ques.2 Explain different roles of the software development?

Ans Definition of Software Development :- Software development (also known as application development, software design, designing software, software application development, enterprise application development, or platform development) is the development of a software product. The term "software development" may be used to refer to the activity of computer programming, which is the process of writing and maintaining the source code, but in a broader sense of the term it includes all that is involved between the conception of the desired software through to the final manifestation of the software, ideally in a planned and structured process. Therefore, software development may include research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

Software can be developed for a variety of purposes, the three most common being to meet specific needs of a specific client/business (the case with custom software), to meet a perceived need of some set of potential users (the case with commercial and open source software), or for personal use (e.g. a scientist may write software to automate a mundane task). Embedded software development, that is, the development of embedded software such as used for controlling consumer products, requires the development process to be integrated with the development of the controlled physical product.

The following are the roles of Software Development based on the Microsoft Solutions Framework (MSF).

Middle-Management Leadership Manage people, resources, and budgets. Oversee and provide vision for several major projects simultaneously. Review employees in all other positions. Work with other MM leaders for interaction between projects.

Team Leadership Manage people, resources, and timelines for one major project or several minor projects. Act as the central point of contact on those projects. Involve or aware of virtually every issue or decision in project. Team Leader is responsible for all aspects of the project. Work with all other positions.

Product Management Work with clients to define requirements and resolve issues. Design and maintain functional specifications and other documentation. Often provide prototypes for user interfaces or design interface of services. Work with Team Leadership and Software Development.

Logistics Manage hardware/software requirements for development, testing, validation, and production environments. Perform or oversee installations. Own the installation process and any installation utilities. Software Project Management Work with resource teams to obtain servers/software and address issues within the environments. Work with Team Leader.

Software Development (Programming) Design and code the software to match the specifications, prototypes, and other documentation. Define timelines. Work with Product Management to refine expectations and clarify requirements. Often interact with Team Leader, Tester, User Documentation, and User Education.

Software Testing Define testing procedures and certification process. Define timelines. Create and execute tests on software. Manage a bug-tracking procedure. Work with Team Leadership. Collaborate with Product Management to define areas and specifics of testing. Often interact with Software Developer. Work with Team Leader.

User Documentation Create and maintain user-centric documentation. Work with Product Management and Software Development to define and document functionality. Often provide training materials for User Education. Work with Team Leader.

User Education Create training procedures and policies. Design training materials. Execute training sessions. Work with Product Management and User Documentation. Work with Team Leader. Software Support Define support procedures. Handle user issues. Provide resolutions or formulate work-around for software issues. Forward hardware/infrastructure issues to Logistics. Notify Software Testing and Development of software bugs. Work with Team Leader.

Ques 3. List out different project development stages in detail?Ans:-Definition of Project Management :-

Project Management is the discipline of organizing and managing resources in such a way that these resources deliver all the work required to complete a project within defined scope, time, and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service that brings about beneficial change or added value. This property of being a temporary and a one-time undertaking contrast with processes, or operations, which are permanent or semi-permanent ongoing functional work to create the same product or service over and over again. The management of these two systems is often very different and requires varying technical skills and philosophy, hence requiring the development of project management. Project Development Stages The project development process will have the same major stages:

Initiation, Planning and design, project implementation and closing/maintenance.

Initiation

The initiation stage determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The key project controls needed here is an understanding of the business environment and makingsure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them. The initiation stage should include a cohesive plan that encompasses the following areas: Study analyzing the business needs in measurable goals.

Review of the current operations.

Conceptual design of the operation of the final product.

Equipment requirement.

Financial analysis of the costs and benefits including the budget.

Select stake holders, including users, and support personnel for the project.

Project charter including costs, tasks, deliverables, and schedule.

This phase can also be called initiation phase, where in people has to identify the following, Information to be processed.

Functions required.

Performance required.

System behavior should be determined

No of interfaces required should be estimated. This may be difficult to do. But tentatively allowed.

Some times project can be dropped during at this phase.

Planning and Design After the initiation stage, the system is designed. Occasionally, a small prototype of the final product is built and tested. Testing is generally performed by a combination of testers and end users, and can occur after the prototype is built or concurrently. Controls should be in place that ensures that the final product will meet the specifications of the project charter. The results of the design stage should include a product design that:

Satisfies the project sponsor, end user, and business requirements.

Functions as it was intended.

Can be produced within quality standards.

Can be produced within time and budget constraints. During this phase the following issues are addressed, How design should be converted into code?

Testing strategy should be planned

Strategy for module integration.

Architectural issues are evaluated

Interfaces are characterized etc. Project Implementation

Against the project plan and project organization structure defined in the previous stage, the project activities are executed, tracked and measured. The project implementation stage not only includes the completion of planned activities, but also the evaluation of the success and contribution of this effort and the continual review and reflection of project status and outstanding issues against the original project business case. The implementation is basically concerned with the development of code and deploying the code. There should be synchronization between the code and design. Tools are available to synchronize both code and design. (Ex: UML – Visual Paradigm, Rational Rose etc). Once implementation is over, proper testing is required. Testing can be unit testing, performance testing, load testing, integration testing and system testing.

Closing and Maintenance One of the key success criteria for continuous process improvement involves defining a formal process for ending a project. This includes evaluating the successful aspects of the project as well as identifying opportunities for improvement, identification of project "best practices" that can be leveraged in future projects, and evaluating the performance of project team members. Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. Maintenance is an ongoing process, and it includes:

Continuing support of end users

Correction of errors

Upgradation of software and hardware etc.

Documentation preparation (user manuals).

Ques.4 Define PERT chart through a suitable example?Ans :- PERT (Program Evaluation and Review Technique) is basically a method to analyze the tasks involved in completing a given project, especially the time needed to complete each task, and identifying the minimum time needed to complete the total project. This project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

A PERT chart is represented with boxes and arrows. Each box represents an activity (ex. Design is an activity, Testing is an activity). The arrows are used to show the dependency of activities on one another. The activity at the head of the arrow cannot start until the activity at the tail of the arrow is finished. For developing his PERT chart, one must first list all the activities required for the completion of the project and estimate how long each will take, and then one must determine the dependencies of activities on one another. Salient Features of PERT Chart: 1) It forces and helps the manager to plan.

2) It shows the interrelationship among the tasks in the project. 3) It exposes the critical path (refer Unit 5) and allows us the opportunity to consider the alternative approaches to cope with a potential problem.

4) It allows scheduling and simulation of alternative schedules.

The PERT chart is sometimes preferred over the Gantt chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

PERT charts are visualization tools commonly used by project managers to control and administer the tasks required to complete a project. The Program Evaluation and Review Technique or Project Evaluation and Review Technique commonly abbreviated PERT is a model for project management to analyze and represent the tasks involved in completing a given project. The most famous part of PERT is the "PERT Networks", charts of timelines that interconnect. PERT is intended for very large-scale, one-time, complex, non-routine projects. Software Project Management

The PERT chart provides a graphical display of Critical Path on a project. Most scheduling tools highlight the activities on the Critical Path. It is useful to include the following information in the activities on the PERT chart: Duration, Float Start date, End date, Resources Float – The amount of surplus time and leeway allowed in scheduling tasks so that the network critical path is maintained on schedule.

Example :-I is assumed that the project work will start on January 1st and the design work will start on Jan 3rd. On the first day, some of the startup works are initiated and the actual design work begins on Jan 3rd. The

design requires 45 days. So, the design should complete as per estimate by Feb 17th. Considering the delays, the activities that follow the design may start on March 7th at the earliest. (Time gap of 17 days are being taken into consideration to handle the unforeseen situations). The dependency arrows help us to compute these earliest start date on the basis of our estimates of the duration of each activity. We could also compute the earliest finish dates, latest finish dates depending upon the kind of analysis we perform.

Ques 5. What is CMM? Explain its various levels?

Ans Definition :- The Capability Maturity Model (CMM), also known as the Software CMM (S W-CMM). The CMM is a process model based on software best-practices effective in large-scale, multi-person projects. CMM was developed by the Software Engineering Institute (SE]J at Carnegie Mellon University in Pittsburgh. The Capability Maturity Model (CMM) is a way to develop and refme an organization’s processes. The first CMM was for the purpose of developing and refining software development processes. The CMM has been retired and not been updated in over 10 years. CMM has been superseded by CMMI (Capability MaturityModel Integration). The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. This model is questionnaire based. The questions are divided into (1) Essentials, (2) Highly desirable. The CMM has been used to assess the maturity levels of organization in areas as diverse as software engineering, system engineering, project management, risk management, system acquisition, information technology (IT) and personnel management. It has been used extensively for avionics software and government project around the world. More specifically, SEI was established to optimize the process of developing, acquiring, and maintaining heavily software-reliant systems for the DoD. Because the processes involved are equally applicable to the software industry as a whole, SEI advocates industry-wide adoption of the CMM. The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

Level 1 - Ad hoc (Chaotic) : It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.

Level 2 - Repeatable : It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.

Level 3 - Defined : It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the  organization

Level 4 - Managed : It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this  level.

Level 5 - Optimized : It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements. 

Ques 6. Explain software reengineering and technical problems of reengineering.

Ans Reengineering takes time; it costs significant amounts of money; and it absorbs resources that might be otherwise occupied on immediate concerns. For all of these reasons, reengineering is not accomplished in a few months or even a few years. Reengineering of information systems is an activity that will absorb information technology resources for many years. That’s why every organization needs a pragmatic strategy for software reengineering. A workable strategy is encompassed in a reengineering process model.

Reengineering is a rebuilding activity, and we can better understand the reengineering of information systems if we consider an analogous activity, the rebuilding of a house.

The reengineering paradigm shown in the figure is a cyclical model. This means that each of the activities presented as a part of the paradigm may be revisited. For any particular cycle, the process can terminate after any one of these activities.

Inventory analysis: Every software organization should have an inventory of all applications. The inventory can be nothing more than a spreadsheet model containing information that provides a detailed description (e.g., size, age, business criticality) of every active application. By sorting this information according to business criticality, longevity, current maintainability, and other locally important criteria, candidates for reengineering appear. Resources can then be allocated to candidate applications for reengineering work. It is important to note that the inventory should be revisited on a regular cycle. The status of applications (e.g., business criticality) can change as a function of time, and as a result, priorities for reengineering will shift. Document Restructuring: Weak documentation is the trademark of many legacy systems. 1) Creating documentation is far too time consuming. If the system works, we’ll live with what we have. In some cases, this is the correct approach. It is not possible to re-create documentation for hundreds of computer programs. If a program is relatively static, is coming to the end of its useful life, and is unlikely to undergo significant change, let it be!

2) Documentation must be updated, but we have limited resources. We’ll use a “document when touched” approach. It may not be necessary to fully re-document an application. Rather, those portions of the system that

are currently undergoing change are fully documented. Over time, a collection of useful and relevant documentation will evolve.

3) The system is business critical and must be fully re-documented. Even in this case, an intelligent approach is to prepare documentation to an essential minimum. Each of these options is viable. A software organization must choose the one that is most appropriate for each case.

Technical Problems of Re-engineering :-Most reengineering tools work only on workstation and PC platforms. This may be due to the trend of client-server, distributed systems processing or it may be due to the versatility and power of mid-sized workstations. Whatever the cause, mainframe-based organizations interested in reengineering face downsizing/downloading of their software to run on these platforms. Thus, an interface issue is introduced both for input to the tool and returning its output to the production platform.

Reengineering tools still have a serious problem handling software written in multiple languages or with embedded macros, DBMS calls, etc. The dominant language is usually COBOL and there are plenty of COBOL reengineering tools available. Usually a platform that allows an integration of tools is the best choice to handle this variety of input. This means the tools can exchange software meta-data. Remember, the reengineering tools will need to interact with metrics tools, validation tools, a repository, documentation tools, etc. The DoD has created the I-CASE (Integrated Computer-Aided Software Engineering) project to allow suites of tools to exchange software meta-data. I-CASE was defined to allow an open architecture that encompasses development tools, maintenance tools, and reengineering tools. If legacy software is not written in a source code language with a sufficient user base, no vendor will deem it economically feasible to create a tool for that language. The same can be said regarding proprietary DBMS or data file system. So we are left with one of three choices:

Manually reengineer or redevelop your systems

Develop your own proprietary tools

Contract with a software reengineering service to reengineer your legacy software