SPID

Dear Masters,

On this page we will create a standard Software Project Implementation Document on which the client work order will be issued. Add your title below and give SAMPLE content for your part of the documentation. Complete this work by July 22nd, 2010, 2pm.

Pasha,

Can you add the 9 titles below from the GREEN cards. Thanks.

-Yousuf

=
=================================================================================================== Of course i can do it for you Sir, The names of the Titles are given below:
 * 1) === **TIME AND BUDGET** ===
 * 2) === **USER ACCESIBILITY TESTING (UAT)** ===
 * 3) === **TECHNIQUES** ===
 * 4) === **TOOLS** ===
 * 5) === **PROCESS** ===
 * 6) === **MODIFICATION** ===
 * 7) === **REPORT** ===
 * 8) === **MANUALS** ===
 * 9) === **SLA** ===

thank U, Sir

=
========================================================
 * Md. Enayet Ullah**
 * ID: 102-25-166**

ID: 102-25-156
*TIME AND BUDGET*
 * Topic 1:** ** TIME AND BUDGET **


 * 1) Time
 * 2) Budget
 * 3) Gantt Chart

Time:
 * **Duration of completion of the software.**
 * **Duration of testing of the software.**
 * **Duration of implementation of the software.**

Budget:
 * **Budget of completion of software with in the target duration.**
 * **Budget of UAT of software with in the target duration.**
 * **Budget of implementation, request based changer & future support of software.**

GANTT Chart:
 * **GANTT chart will show the dependency on time for the project completion.**
 * **GANTT chart will show the dependency on budget for the project completion.**

**Md. Enayet Ullah** **ID: 102-25-166**

[[#x1.Modification:-Md. Aliullah Bhuiyan, ID: 093-25-138-MUHAMMAD PASHA (102-25-165)---
==============================================================================================]]========================================================================================================== Comment or question by other group member: **USER ACCESIBILITY TESTING (UAT)** Name/ID: **Md. Masudur Rahman (101-25-152)**

__**Question:**__

Thnx Mr. Enayet & Mr. Fakri. Your topic is **Time and Budget**, I know that manpower problem solving is the part of your topic but you do not discuss for this subject, so how can solve/arrange it (Manpower)?

Response by one member of this group:

Name/ID: Ahammad Fekri (102-25-156)
Dear Mr. Masud we appreciate your question, We have considered man power cost. In Gantt Chart details part we will show human factor and cost analysis there the cost will be specified. Thanks again and we will be happy if we can help you more..

[[#x1.Modification:-Md. Aliullah Bhuiyan, ID: 093-25-138-MUHAMMAD PASHA (102-25-165)---
==============================================================================================]]========================================================================================================== Comment or question by other group member: **PROCESS** Name/ID: ** Susmita Baidya, ID: 102-25-158 **

On which basis you will calculate the budget of request based changing? Is there any time limit of change request (suppose, during implementation period or within one month)?
 * __Question:__**

Response by one member of this group:

Name/ID: Ahammad Fekri (102-25-156)
Thanks Susmita for your nice question. We do agree with you that many kinds of changes may happen in development period or after development. When any change will come then will look at gantt chart. Where everything is calculated previously. We will re-calculate the cost and time from gantt chart according to change request. Then we can found easily change cost and time. I think you have got your answer and we will be happy if we can help you more...

//**By:**//
 * //Sample Content for the topic “//**//Tools**” of the documentation**//
 * //Sample Content for the topic “//**//Tools**” of the documentation**//
 * //Muhammad Ashik Iqbal (092-25-127)//
 * // Muhammed Samsuddoha Alam (093-25-139) //

**
================================================**====== Platform: Hardware: __Client:__ Systems: __Client:__ Database:
 * 4. Tools Required for the System **
 * __Server:__**
 * **Microsoft Windows Server 2008**
 * __Client:__**
 * **Microsoft Windows XP/Vista/7**
 * __Server:__**
 * Intel Xeon Processor [|3000] Series
 * 32 GB RAM
 * 2 x 5TB Storage
 * DVD-RW Drive
 * Intel Core i5
 * 2GB RAM
 * 500GB HDD
 * DVD-RW Drive
 * Laser Printer
 * __Server:__**
 * IIS 7.0
 * DotNET Framework 4.0
 * Crystal Report 2010
 * Microsoft Team Foundation Server
 * SharePoint Server 2010
 * Microsoft Office 2010
 * Internet Explorer 8.0
 * Mozilla Fire Fox 3.x
 * DotNET Framework 4.0
 * Microsoft Silverlight 4.0
 * __Server:__**
 * **Microsoft SQL Server 2008 R2**

Comment or question by other group member: ** USER ACCESIBILITY TESTING (UAT) ** Name/ID: ** Roni Shikder **

__**Question:**__ In case of using Tools and Techniques we need to think about budget also. Do you think about user budget before using these tools and techniques (like 32GB RAM, Intel Core i5) ?

Response by group member: good question. yah,budget is a big factor but you know user always want more with less ivestment. In such situation the above tools may be needed [it is an approximation about tools]. If the user wants more then you have to give proper clarification about tools so that they can be convinced by your clarification. Most importantly it will be better if we can give requirements with the clarification like "why is it needed?+ budget".

093-25-139

 * Response by this group member:**

Thanks Mr. Roni for your interest. The configuration shown here is only for SAMPLE content. Yes, off course the budget will be in our concern. But at least the minimum requirements should be followed to get the performance.

With Thanks,
 * Muhammad Ashik Iqbal **
 * 092-25-127 **

Question by Haider Ali ID:101-25-154 Well in a country like Bangladesh has tendency to spend less in IT infrastructure.So dont you think 32 GB RAM would be extravagant? My second question is why Silverlight is needed or what is the function of Microsoft Silverlight 4.0?And why recommend IE 8 AS well as Firefox(Isn't one browser is enough?) I think you should reduce your requirement otherwise client would be confused.

//__ **CHAPTER-07** __// //__ **PROGRESS REPORT** __//
 * Md. Kamrul Hasan Chayon ID-> 101-25-142 **
 * Achia Khaleda Nila ID-> 092-25-133 **
 * Achia Khaleda Nila ID-> 092-25-133 **


 * Progress reports are common in engineering. Its goal is to enable the manager or sponsor of a project to make informed decisions about the future of the project. Usually, progress reports are stressful. The sponsor wants a job done quickly and cheaply; the engineer needs to ensure **accuracy **and** quality**. A sponsor might cancel even a quality job if it is behind or over budget. As the engineer, you need to please the sponsor** and **do the job well. The introduction can contain the following:**
 * **Purpose of the project**
 * **Specific objectives of the project**
 * **Scope, or limits, of the project**
 * **Date the project began; date the project is scheduled to be completed**
 * **People or organization working on the project**
 * **People or organization for whom the project is being done**
 * **Overview of the contents of the progress report**
 * In the progress report, you explain any or all of the following:**
 * **How much of the work is complete**
 * **What part of the work is currently in progress**
 * **What work remains to be done**
 * **What problems or unexpected things, if any, have arisen**
 * **How the project is going in general**
 * Progress reports have several important functions:**
 * **Reassure recipients that you are making progress, that the project is going smoothly, and that it will be complete by the expected date.**
 * **Provide their recipients with a brief look at some of the findings or some of the work of the project.**
 * **Give their recipients a chance to evaluate your work on the project and to request changes.**
 * **Give you a chance to discuss problems in the project and thus to forewarn recipients.**
 * **Force you to establish a work schedule so that you'll complete the project on time.**


 * In a year-long project, there are customarily three progress reports, one after three, six, and nine months. Depending on the size of the progress report, the length and importance of the project, and the recipient, the progress report can take the following forms:**
 * Memo**—A short, informal report to someone within your organization**
 * Letter**—A short, informal report sent to someone outside your organization**
 * Formal report**—A long, formal report sent to someone outside your organization**

 // Time periods: // **A progress report usually summarizes work within each of the following:**
 * The recipient of a progress report wants to see what you've accomplished on the project, what you are working on now, what you plan to work on next, and how the project is going in general. To report this information, you combine two of these organizational strategies: time periods, project tasks, or report topics.**
 * **Work accomplished in the preceding period(s)**
 * **Work currently being performed**
 * **Work planned for the next period(s)**

// Project tasks: // **Practically every project breaks down into individual tasks:**
 * · Studying the assignment**
 * · Selecting a topic**
 * · Identifying the audience of the report**
 * · Narrowing the topic**
 * · Developing a rough outline**
 * · Gathering information**
 * · Writing one or more rough drafts**
 * · Documenting the report**
 * · Revising and editing the report draft**


 * As you reread and revise your progress report, watch out for problems such as the following:**
 * **Make sure you use the right format. Remember, the memo format is for internal progress reports; the business-letter format is for progress reports written from one external organization to another. (Whether you use a cover memo or cover letter is your choice.)**
 * **Write a good introduction-in it, state that this is a progress report, and provide an overview of the contents of the progress report.**
 * **Make sure to include a description of the final report project.**
 * **Use one or a combination of the organizational patterns in the discussion of your work on the final report.**
 * **Use headings to mark off the different parts of your progress report, particularly the different parts of your summary of work done on the project.**
 * **Use lists as appropriate.**
 * **Provide specifics-avoid relying on vague, overly general statements about the work you've done on the final report project.**
 * **Be sure and address the progress report to the real or realistic audience-not your instructor.**
 * **Assume there will no specialist reading your progress report. But don't avoid discussion of technical aspects of the project—just bring them down to a level that no specialists can understand.**

Comment or question by other group member: **PROCESS** Name/ID: ** Susmita Baidya, ID: 102-25-158 **

What about the schedule of preparing progress report? Is it fixed or prepared by user requirement? ANS: Thank you Susmita. There will be a schedule, but that will contain the time schedule of the completing tasks, the up coming tasks and also the running tasks. This time schedule is not same as GANN CHART, but it may follow the time. This is a progress report, so it will provide a report which shows the progress of project or task.
 * __Question:__**
 * REPLIED BY: Md. Kamrul Hasan CHAYON 101-25-142 **

- **%%%%%%% Comment's or question's Section %%%%%%%**

Name/ID: ** Abu Sayem Shahadat, ID: 101-25-156 **

 * __Question:__**

**If any changes occur in the system what will be the affect in your general reporting schedule?**
ANS:
 * Replied By: Md. Kamrul Hasan CHAYON, 101-25-142 **

=
Thank you Mr. Sayem. Please, you are requested to see the answer (answer for the question of Susmita) stated above. So, no special tools are nedded. If any changes are occurred in the system, there will be no affect in the general reporting schedule. Cause, the progress report is a continuous tasks. =====

I want add something with Chayon, we can use Silver light Viewer, comindwork, Chrystal report etc as a reporting tools.
 * Replied By: Achia Khaleda Nila, 092-25-133 **



Md. Azharul Haque,ID:102-25-167
** Chapter 06 ** = Modification =

= 1.Modification**:** =

of the software need to update software.

 * 2.Management: **

if everyone knew that this functionality was expected all along.
consider an error then send it to the development team otherwise it will be enhanced of the system and included it to SRS (System Requirement Specification) as a written document.
 * C. ** At first we consider, the problem is an error or enhancement of the system. If we

money for new works.
**4.Documents:**

Md. Azharul Haque,ID:102-25-167


**%%%%%%% Comment's or question's Section %%%%%%%** Comment or question by other group member

= Comments by Khaled Mahmud, ID# 092-25-132 =

__Comments:__ First of all, versioning is very important while writing documentation for a software. It keeps track of modification in the documentation. So, whenever, we go for modification, we have to keep versioning. Versioning also helps other system analyst to understand about the current situation of any software.

Name/ID: Khaled Mahmud (092-25-132)

Question:
You said " Documentation for the modification is not also needed because of all the procedure and specification ====clarified in SRS (System Requirement Specification) by the Stakeholder" which is not true. In this case, What does documentation stand for? You have to change in SRS and some other part of the documentation at the same time, like Scope of work, Budget, Database etc.==== ====However, you said that "If Stakeholder wants to enhance any part of the system then the documentation is needed". This is also not clear because if stakeholder wants to enhance any part of the system, that is modification, then documentaton is needed. So, you said that documentation is not needed for the modification and at the same time, you also said that if stakeholder wants to enhance then documentation is needed. This is self contradictory. My question is, which parts need to be modified in the documentation when changes come in the system?====

Thanks in advanced.
Name/ID: Khaled Mahmud (092-25-132)

Md. Azharul Haque,ID:102-25-167
Documentation needed for the purpose of developing a new system that are prepared by the stakeholder where each and every points are clarified. Stakeholder prepared document (SRS) considering their business or what they needed? If they change their business or stop the project we did not liable. It's stakeholders headache. Our one and only concern is to prepare system using SRS.


 * Mr. Muhammed Samsuddoha Alam, Modification and Enhancement is not same think**. We are taking here about after UAT modification not enhancement of the system that are discussed in our class. So that if any error occurred then we resolved all the errors by the help of SRS. When stakeholder change their business then write another document and added it to our SRS. it will be enhancement of the system not existing system change.

QUESTION BY MUHAMMED SAMSUDDOHA ALAM, ID#093-25-139
QUESTION: thanks for your description. according to your description you are saying "

Version management is not essential for the modification stage because of the system UAT running.
That’s why version will be remaining unchanged."quoted from your description.

So, if version is not essential then why r you inserting version in modification part?
or

Md. Azharul Haque,ID:102-25-167

 * Modification, Management, Version and Documentation** all bullet parts are provided by our teacher and he told us write all bullets in your team chapter-13 (Managing Changes of Software) aspects. That's why we write it in our document and explain in our own selected chapters aspect not more than that.

Md. Azharul Haque,ID:102-25-167

 * Name/ID: Muhammad Pasha (102-25-165) **


 * __Question:__**
 * Dear Members, very nice explanation of course. I need some more information about the Versions.**


 * Would you please mention the key points (bullets) for:**
 * 1. What is the necessity of the new Version OR, Why your company will launch the new Versions?**
 * 2. And What new things can be added on the newer Versions?**

Comment or question by:
 * Thank U**
 * Name/ID: Muhammad Pasha (102-25-165) **

Md. Aliullah Bhuiyan, ID: 093-25-138

 * First one:** New version is necessary to track system change. If any enhancement required then company prepare new document and added it to the existing document after that submit to the development team. When enhanced completed then **Update/Increase Version Number** else not.
 * Second one:** That will be submitted by the stakeholder. Because of, developer team did not know the stakeholder business and they are developing just customized software. So, **Newer Version** contain stakeholder provided part of the system.

Md. Aliullah Bhuiyan, ID: 093-25-138
Comment or question by other group member:

Name/ID: Ahammad Fekri (102-25-156)
__Question__ This a good description but some topics could be more clear. If any modification is required then how do you calculate the extra cost...? and how do you understand this is not in the requirements list this is extra work...?

Md. Aliullah Bhuiyan, ID: 093-25-138
We are taking about after UAT modification not enhancement. That's why not necessary to analysis extra cost. If stakeholder demand to enhance any part of the system then re-documentation is needed else not necessary.

Md. Aliullah Bhuiyan, ID: 093-25-138
** Roni Shikder, ID: 102-25-159 ** ** Md. Masudu Rahman. ID: 101-25-152 **
 * ##################################################################### **

Chapter # 02 USER ACCESIBILITY TESTING (UAT)

What is User Acceptance Testing?
 * User Acceptance Testing is often the final step before rolling out the application. **


 * Usually the end users who will be using the applications test the application before ‘accepting’ the application. **


 * This type of testing gives the end users the confidence that the application being delivered to them meets their requirements. **


 * This testing also helps nail bugs related to usability of the application. **


 * <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">Phases of software development in which the software is tested in the "real world" by the intended audience **
 * - <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">Beta testing **
 * - <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">Application testing and **
 * - <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">End user testing. **
 * <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">UAT can be done by in-house testing in which volunteers or paid test subjects use the software or, more typically for widely-distributed software, by making the test version available for downloading and free trial over the Web. The experiences of the early users are forwarded back to the developers who make final changes before releasing the software commercially. **

<span style="color: #17375e; font-family: 'Arial','sans-serif'; font-size: 9pt;">User Acceptance Testing – Prerequisites:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Before the User Acceptance testing can be done the application is fully developed. Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT. **

<span style="color: #17375e; font-family: 'Arial','sans-serif'; font-size: 9pt;">User Acceptance Testing – What to Test?
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">To ensure an effective User Acceptance Testing Test cases are created. These Test cases can be created using various use cases identified during the Requirements definition stage. The Test cases ensure proper coverage of all the scenarios during testing. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">During this type of testing the specific focus is the exact real world usage of the application. The Testing is done in an environment that simulates the production environment. The Test cases are written using real world scenarios for the application **

<span style="color: #17375e; font-family: 'Arial','sans-serif'; font-size: 9pt;">User Acceptance Testing – How to Test?
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The user acceptance testing is usually a black box type of testing. <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">In other words, the focus is on the functionality and the usability of the application rather than the technical aspects. It is generally assumed that the application would have already undergone Unit, Integration and System Level Testing. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The steps taken for User Acceptance Testing typically involve one or more of the following: **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">1) User Acceptance Test (UAT) Planning **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">2) Designing UA Test Cases **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">3) Selecting a Team that would execute the (UAT) Test Cases **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">4) Executing Test Cases **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">5) Documenting the Defects found during UAT **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">6) Resolving the issues/Bug Fixing **
 * <span style="color: white; font-family: 'Arial','sans-serif'; font-size: 9pt;">....... <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">7) Sign Off **

//<span style="color: #4f4f4f; font-family: 'Verdana','sans-serif'; font-size: 9pt;">User Acceptance Test Process Flow // <span style="color: #4f4f4f; font-family: 'Verdana','sans-serif'; font-size: 9pt;">


 * <span style="color: #4f4f4f; font-family: 'Verdana','sans-serif'; font-size: 9pt;">The MIND Professional UAT group uses a special testing methodology and technique combined with specific testing tools in order to simulate the following for a group of key users: **
 * <span style="font-family: 'Verdana','sans-serif'; font-size: 9pt;">**Validating system set-up for transactions and user access**
 * <span style="font-family: 'Verdana','sans-serif'; font-size: 9pt;">**Confirming system use in performing business processes**
 * <span style="font-family: 'Verdana','sans-serif'; font-size: 9pt;">**Verifying performance in critical business scenarios**
 * <span style="font-family: 'Verdana','sans-serif'; font-size: 9pt;">**Confirming integrity of converted and additional data**
 * <span style="font-family: 'Verdana','sans-serif'; font-size: 9pt;">**Assessment and sign off of go-live readiness**

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">User Acceptance Test (UAT) Planning:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">As always the Planning Process is <span style="font-family: 'Arial','sans-serif'; font-size: 9pt;">the most important of all the steps. This affects the effectiveness of the Testing Process. The Planning process outlines the User Acceptance Testing Strategy. It also describes the key focus areas, entry and exit criteria. **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Designing UA Test Cases:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The User Acceptance Test Cases help the Test Execution Team to test the application thoroughly. This also helps ensure that the UA Testing provides sufficient coverage of all the scenarios. The Use Cases created during the Requirements definition phase may be used as inputs for creating Test Cases. The inputs from Business Analysts and Subject Matter Experts are also used for creating. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The Business Analysts and the Project Team review the User Acceptance Test Cases. **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Selecting a Team that would execute the (UAT) Test Cases:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Selecting a Team that would execute the UAT Test Cases is an important step. The UAT Team is generally a good representation of the real world end users. The Team thus comprises of the actual end users who will be using the application. **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Executing Test Cases:


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The Testing Team executes the Test Cases and may additional perform random Tests relevant to them **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Documenting the Defects found during UAT:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The Team logs their comments and any defects or issues found during testing. **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Resolving the issues/Bug Fixing:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The issues/defects found during Testing are discussed with the Project Team, Subject Matter Experts and Business Analysts. The issues are resolved as per the mutual consensus and to the satisfaction of the end users. **

<span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Sign Off:
 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">Upon successful completion of the User Acceptance Testing and resolution of the issues the team generally indicates the acceptance of the application. This step is important in commercial software sales. Once the User “Accept” the Software delivered they indicate that the software meets their requirements. **


 * <span style="color: black; font-family: 'Arial','sans-serif'; font-size: 9pt;">The users now confident of the software solution delivered and the vendor can be paid for the same. **

=
=================================================================================================== Comment or question by other group member: Name/ID: Abdur Rahman Bhuiyan [ID: 093-25-140]

USER ACCESIBILITY TESTING (UAT).
 * __Question:__**
 * Thank you Mr.Roni Shikder and Md. Masudu Rahman for working on **


 * In your report you posted**
 * “ This type of testing gives the end users the confidence that the application being delivered to them meets their requirements. “**
 * Now my question is** **what sort of raw data you will use for UAT and before pass the UAT from top management [Like Mr. Prof. Younus] how can you deliver your software to end users?**
 * Thanks **

Response by one member of this group: **Roni Shikder, ID # 102-25-159** <span style="font-family: 'Times New Roman','serif';">Thanks for your query. We will use the real data that’s used by the end user in manual process. ** Mr. Prof. Younus is the top management of End users but he doesn’t use this. He will only view the output. Some concern officers of him who are going to use and monitor this, we will apply the UAT by these types of end users. During UAT the both process (manual and computerized) are going in parallel, so we can easily compare the result. **
 * <span style="font-family: 'Times New Roman','serif';">Answer **<span style="font-family: 'Times New Roman','serif';">:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
===================================================================================================


 * <span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">############################################################################### **

__Topic 2:__ __PROCESS__ :
 * //SCOPE OF WORKS & OVERVIEW//**


 * prepared by :**

Khaled Mahmud (092-25-132)
__1. SCOPE OF WORKS:__

__PROCESS:__ This section describes the overall working process of the software. How the System is designed put a data by put it as an input as well as get back the data as the output. The various kinds of reports generating procedures also has been described over this section.

The implementation techniques of a software can be suggested as an additional feature on this section of the document.

Process also describe the Branch wise, Area wise or Zone wise Report generating. It also can describe the report details to the Head Quarter's point of view.

__BENEFITS:__ If the process is described very clearly, a software can be understand very easily by any knowledgeable person.

__2. OVERVIEW:__

The overview including all the Processes can be plotted as a Mind Map, which is also given over here:




 * prepared by : **

MUHAMMAD PASHA (102-25-165)

 * Susmita Baidya, ID: 102-25-158 **
 * A** software development process **is a structure imposed on the development of a software product.**
 * The purpose of this document is to define the project, to form the basis for its management and the assessment of overall success.**


 * In any transition program there are a number of standard questions to answer and this will be referred to as the process improvement model.**

Figure 1: Process Improvement Model Software development process **__ Architecture __** · **__ Design __** **__ Implementation __** · **__ Testing __** **__ Deployment __** · **__ Maintenance __** || **__ Iterative __** · **__ RAD __** · **__ RUP __** · **__ Spiral __** __ Documentation __ __ Quality assurance (SQA) __ __ Project management __ __ User experience design __ ||
 * Software development process ||
 * Activities and steps ||
 * __ Requirements __ · **__ Specification __**
 * Methodologies ||
 * __ Agile __ · **__ Cleanroom __** ·
 * __ Waterfall __** · **__ Lean __**
 * __ V-Model __** · **__ TDD __** ||
 * Supporting disciplines ||
 * __ Configuration management __
 * Tools ||
 * __ Compiler __ · **__ Debugger __** · **__ Profiler __**
 * __ GUI designer __**


 * __ Integrated development environment __** ||

Software development activities




 * The activities of the software development process represented in the model. There are several other models to represent this process.**


 * The mind map of the overall process will be given later. **
 * Project Initiation Document **
 * · This document is produced to capture and record the basic information needed to correctly direct and manage the project. **
 * · The PID addresses the following fundamental aspects of the project: **
 * o What the project is aiming to achieve **
 * o Why it is important to achieve the stated aims **
 * o Who will be involved in managing the project and what their roles and responsibilities are. **
 * o How and when the arrangements discussed in this PID will be put into effect. **
 * · When approved by the Project Board this PID will provide the “Baseline” for the project and will become “frozen”. **
 * · It will be referred to whenever a major decision is taken about the project and used at the end of the project to measure whether the project was managed successfully and delivered an acceptable outcome for the sponsor/user/customer. **
 * Communication Plan **
 * · This document identifies who needs to be kept ‘in the loop’ as part of the project, by what method and how often. **
 * · It is included and updated within the PID. **

=
======================================================================================= Comment or question by other group member: **USER ACCESIBILITY TESTING (UAT)** Name/ID: **Md. Masudur Rahman (101-25-152)**

__**Question:**__ Thnx Mr. Pasha for your nice Mind Map, I think your topic is **Process** that means Scope of works and overview. But my question is "What do u mean by Overview? Is it the hole procedure/items of Documentation like Manual, SLA?"

Response by one member of this group: Name/ID:** MUHAMMAD PASHA (102-25-165) **

Answer to **Md. Masudur Rahman (101-25-152)**,

Thank u, for asking a nice question. Actually, I have been waiting for this question.

If we wonder, the overall software will be implemented in Grameen Bank which has 600 branches located in Rural or Urban or Semi-Urban area, there must be some Expected but Unknown problem may occur, for example, the Mice may cut the cables and etc. The Project manager will never been have an overview before, unless the Mice do so. These are the Scope of works, which is totally depend on the Natural or other situation and the whole scenario will be seen when we will go for the Process implementation.

A project manager will never guess exactly all the situations will rise on the Implementation process, but he/she may have few overviews from his past experience. So, in the documentation a manager can never guess and write what problem would be occur and what would be the solution, before the problem may rise.

I think, i could make u clear ( from my points of view ) the Process, Overview and Scope of works

thank u once again


 * MUHAMMAD PASHA (102-25-165) **

[[#x1.Modification:-Md. Aliullah Bhuiyan, ID: 093-25-138-MUHAMMAD PASHA (102-25-165)---
==============================================================================================]]================================ ========================================================================== Comment or question by other group member:

Name/ID: Ahammad Fekri (102-25-156)

 * __Question:__**
 * We have some color full presentation here but I have a bit of confusion about your mind map. I mean which part do you consider as major processes in your mind map as we found planning, budgeting everything in your mind map?**

Response by one member of this group: Name/ID: **Susmita Baidya, ID: 102-25-158** <span style="font-family: Georgia,serif;">**<span style="font-family: 'Garamond','serif'; font-size: 12pt; line-height: 115%;">Answer **<span style="font-family: 'Garamond','serif'; font-size: 12pt; line-height: 115%;">: <span style="font-family: Georgia,serif;"><span style="font-family: 'Garamond','serif'; font-size: 12pt; line-height: 115%;">As we can see the Process includes //**<span style="font-family: 'Garamond','serif';">SCOPE OF WORKS & OVERVIEW **////<span style="font-family: 'Garamond','serif'; font-size: 12pt; font-style: normal; line-height: 115%;">so we combine budget, planning manpower, tools, techniques etc. all the aspect of a project. We also includes gnat chart here. By using gnat chart we can find the time against a specific work, who is responsible for th ////<span style="font-family: 'Garamond','serif'; font-size: 12pt; font-style: normal; line-height: 115%;">at ////<span style="font-family: 'Garamond','serif'; font-size: 12pt; font-style: normal; line-height: 115%;"> work and also the budget. It is the main thing we are going to obtain from here. //





*%%%%%%%%%%% **Comment or question Section** %%%%%%%%%%%% Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
=================================================================================================== Comment or question by other group member: Name/ID:


 * __Question:__**

Response by one member of this group: Name/ID:

=
===================================================================================================

<span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">##############################################################################################

<span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">Topic 3:

<span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">Techniques:

<span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">Prepared by: Chowdhury Tanvir Jalil (ID:092-25-129) <span style="background-color: #f1d5d5; color: #8210da; font-family: 'Arial Black',Gadget,sans-serif; font-size: 120%;">Sazib Chowdhury (ID:092-25-130)

Introduction Thick methodology: **A methodology that includes a large amount of formal process paperwork and documentation.** Thin methodology: **A methodology that eschews formal process paper work and documentation.** Methodologies Rational Unified Process (RUP) SSADM PRINCE2 Extreme Programming (XP) Principles of XP Scrum Sprint: **A period of 30 days or less where a set of work will be performed to create a deliverable** Backlog: **All work to be performed in the foreseeable future, both well defined and requiring further definition.** Sprint backlog: **The work that should be done during the current sprint.** Product backlog: **The work that should be done for the whole product as desired by the customer.** Crystal Clear Project Management Body of Knowledge (PMBOK) Constructive Cost Model (COCOMO) Milestone Trend Analysis (MTA) Managing Software Project Risks: **Risk management is concerned with identifying potential risks for your project and then putting a plan together to deal with them if they occur.**
 * There exist numerous project management methodologies and techniques in the world. Except for the usage also the availability of information and resources on the subject was a factor in selecting the methodologies and techniques. Since there seems to be a lot of confusion, or at least different opinions, concerning the meaning of the following definitions, they are defined here as they are used in the remainder of this document.**
 * Thick methodologies are RUP, SSADM and PRINCE2. XP, SCRUM and Crystal Clear are considered as thin methodologies.**
 * The Rational Unified Process (RUP) is a software design methodology created by the Rational Software Company. The Rational Software Company was acquired by IBM in 2003. RUP is a thick methodology; the whole software design process is described with high detail. RUP is hence particularly applicable on larger software projects. The RUP methodology is general enough to be used out of the box, but the modular nature of RUP it is designed and documented using Unified Modeling Language (UML) also makes it easy to adapt the methodology to the special needs of a single project or company. One of the major differences between RUP and other methodologies like SSADM is that RUP doesn’t use a waterfall approach for software development. The phases of requirements, analysis, design, implementation, integration and testing are not done in strict sequence. In RUP, an iterative approach is used: a software product is designed and built in a succession of incremental iterations. Each iteration includes some or most of the development disciplines.**
 * Structured Systems Analysis and Design Methodology (SSADM) is a widely used computer application development method in the UK. Just like PRINCE its use is often specified as a requirement for government computing projects. Today it is increasingly being adopted by the public sector in Europe. SSADM has been used by the government in computing since its launch in 1981. It was commissioned by the Central Computing and Telecommunications Agency (CCTA) in a bid to standardize the many and varied IT projects being developed across government departments. The CCTA investigated a number of approaches before accepting a tender from Lear month & Burchett Management Systems to develop a method. Since 1981 SSADM has been further developed and refined and in 1990 version 4 of it was launched. SSADM is an open standard, which means that it is freely available for use in industry and many companies offer support, training and Computer Aided Software Engineering tools for it.**
 * Projects in Controlled Environments (PRINCE) is a project management methodology covering the organization, management and control of projects. A project has a clear beginning, middle and end, a clear organizational structure and defined objectives. You can use a managing methodology like PRINCE to ensure that a project is successful, which means that it finishes on time, within budget and provides the customer with what they have asked for PRINCE was first developed by the CCTA, which is now part of the O ce of Government Commerce, in 1989 as a UK Government standard for IT project management. Since its introduction, PRINCE has become widely used in both the public and private sectors and is now the de facto standard for project management in the UK. Although PRINCE was originally developed for the needs of IT projects, the methodology has also been used on many non-IT projects. The latest version of the methodology, PRINCE2, is designed to incorporate the requirements of existing users and to enhance the methodology towards a generic, best practice approach for the management of all types of projects. PRINCE2 is a process-based approach for project management providing an easily tailored and scalable methodology for the management of all types of projects. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out. The methodology describes how a project is divided into manageable stages enabling efficient control of resources and regular progress monitoring throughout the project. The various roles and responsibilities for managing a project are fully described and are adaptable to suit the size and complexity of the project, and the skills of the organization.**
 * XP is a software engineering methodology that has been formulated in 1996 by Kent Beck. XP has received fair media attention, and is most renowned for its practices that are sometimes regarded as controversial, such as pair programming and test-driven development.**
 * XP aims to reduce the risk involved in software development. It aims to reduce the cost of delaying design decisions. Traditionally, the cost of making decisions about a software project would rise exponentially during the course of development. It would therefore be costly to defer options, because implementing them later on might be too costly, and possibly even cost more than the value of the option would be. XP reduces the cost of making modifications later on during development, and thereby allows decisions that entail high risk to be deferred until a sound judgment can be made on them. All practices of XP work together to achieve this goal.**
 * Scrum is an agile method for project management, in use since at least 1990. It has been called a hyper-productivity tool, and has been documented to drastically improve productivity in teams previously paralyzed by heavier methodologies quickly producing results where there had been little or none. Scrum uses the following concepts:**
 * Crystal Clear is a highly optimized way to use a small, collocated team, prioritizing for safety1 in delivering a satisfactory outcome, efficiency in development, and habitability of the working conventions. The Crystal Clear methodology is part of the Crystal family of methodologies, where every methodology is characterized by a color (Clear, Yellow, Orange, Red, Maroon, Blue and Violet). That color represents the number of people for which the methodology is suited; Crystal Clear is the lightest color and is meant for the smallest project groups, of two to eight people. Darker colors are for larger groups these will not be discussed here. Crystal Clear has at its core seven properties that should be established for every project that wishes to adhere to the methodology. While all of these are desired, only the first three are mandatory; the other four will get the project further into the safety zone.**
 * The Project Management Body of Knowledge is an inclusive term that describes the sum of knowledge within the profession of Project Management (PM). As with other professions such as law, medicine, and accounting, the body of knowledge rests with the practitioners and academics that apply and advance it. The full Project Management Body of Knowledge (PMBOK) includes knowledge of proven traditional practices that are widely applied, as well as knowledge of innovative and advanced practices that have seen more limited use, and includes both published and unpublished material. The PMBOK framework splits the project processes into five distinct process groups: initiating, planning, executing, controlling and closing. Note that these groups do not imply that the project has to go through each one in this order; they are only provided in order to be able to structure and categorize the different project processes. PMBOK also identifies several project knowledge areas: integration management, scope management, time management, cost management, quality management, human resource management, communications management, risk management and procurement management. The PMBOK Guide includes summaries of generally accepted techniques and methodologies that can be used to implement these project processes. Note that these techniques and methodologies need not be, and mainly are not courtesy of PMBOK. Generally accepted means being applicable to most projects most of the time and having widespread consensus about their value of usefulness.**
 * COCOMO is an empirical, algorithmic model for estimating the e ort, schedule and costs of a software project. It was derived by collecting relevant data from a large number of software projects, then analyzing the data to discover the formulae that were the best-fit to the observations. The first version of the COCOMO model was a three-level model where the levels reflected the detail of the analysis of the cost estimate. The first level provided an initial, rough estimate; the second level modified this using a number of project and process multipliers and the most detailed level produced estimates for different phases of the project. COCOMO 81 makes various assumptions about the software development process in order to produce its estimates. The latter will only be somewhat accurate when the project uses the waterfall process model and every line of code is produced from scratch. It also fails to take into account that nowadays higher-level programming languages are employed, supported by various automated tools. We will not elaborate on this version, since it has been obsolete by COCOMO 2. COCOMO 2 includes support for various development methodologies such as component-based development and prototyping, fourth generation programming languages and CASE support tools. COCOMO 2 still consists of three levels, but these have been given slightly different interpretations: The early prototyping level: Size estimates are based on object points. These object points are a simple way of quantifying the perceived complexity of requirements that need to be implemented. The required e ort is then computed by applying a simple extrapolation from the object points and programmer productivity. Object points are based on the number of screens, reports and modules in third generation programming languages, and can be weighed by the perceived complexity of the screen, report or module in question. The early design level: This level corresponds to the completion of the system requirements with some initial design. Estimates are based on function points, which are obtained by working out the object points in detail.**
 * MTA is a software engineering technique for evaluating the actual progress of a project in relation to its planning. This relatively simple technique consists of recording the dates of the milestone deadlines at the times they are changed, i.e. when they are postponed or advanced. This way one gets a matrix of data: the columns of the matrix delimit the project milestones, the rows the dates on which the deadlines were reevaluated, while an actual cell contains the new deadline estimate for the milestone in question. Of course, one can greatly enhance insight in these data by using some simple visualization techniques. This can be done by plotting the estimated deadlines against the dates on which they were evaluated. The latter are usually placed on the X-axis, the former on the Y-axis. The evolution of a project milestone deadline is thus visible as a curve on the graph: downward movement of the curve signifies that the deadline in question was advanced, while upward movement means postponement. One can also easily spot milestone completion: this is the case when the curve intersects the line y = x. The general shape of the graph is often roughly triangular: this is the result of the fact that we stop plotting a curve when the milestone in question has reached completion, i.e. when it intersects with the angular bisector of the first quadrant.**

Risk management plan


 * 1. The project scope statement**
 * 2. The project management plan**
 * 3. Your organization’s risk tolerance strategy**
 * 4. If a organization already has certain methods for defining terms and concepts for creating risk categories we should use them when defining our project plan. Some examples of risks are given below.**
 * 5.**

Typical Risks:


 * 1) **Key Resources leaving the project**
 * 2) **Technology becoming obsolete**
 * 3) **Stakeholders attempting to enhance the scope of the project**
 * 4) **Leadership changing direction**
 * 5) **Labor disputes**
 * 6) **Schedule delays due to issue with off-site resources**
 * 7) **Personal resources being squeezed because they are involved on too many projects simultaneously**
 * 8) **Lack of commitment on project funding**
 * 9) **Software testing revealing major bugs that could impact the time line.**

Making a plan: **Each of the risk management process has particular tools and techniques that we can use when we develop our risk management plan.**


 * i. Risk management planning**
 * ii. Risk identification**
 * iii. Qualitative risk analysis**
 * iv. Quantitative risk analysis**
 * v. Risk response planning**
 * vi. Risk monitoring and control**

Identifying real risks: **Some techniques of gathering information for risk management plan.**


 * 1. Brainstorming**
 * 2. SWOT analysis**
 * 3. Delphi**
 * 4. Root cause analysis**
 * 5. Interviewing**
 * 6. Don’t reinventing the wheel**

Monitoring and Controlling Risks: **We may create a database to keep track of each previously identified risk, identify and document new risk and track the response plans for each risk.**

Managing secondary and residual risks: **Secondary risk occurs because of a planned risk response. A residual risk is a risk does not go away. We cannot avoid it. But still we need to mange those risks.**

=
============================================================================ Comment or question by other group member:

We know the technology is changing rapidly. If such a condition come, where the technology is totally changed after developing the software. In this situation if the developed software is not compatible with the new technology/platform then that to do? And how to mitigate such types of risks?


 * Muhammad Ashik Iqbal **
 * ID: 092-25-127 **

Response by one member of this group:

Name/ID:Chowdhury Tanvir Jalil(092-25-129)

Thank you, Mr.Ashik for your question.At the time of developing the software we keep a provision in our software so that it can cope up with new technology and compatible with different platforms.We may release new patch or version to make our software work with new up coming technology.

=
==================================================================================================================== <span style="background: none repeat scroll 0% 0% #f1d5d5; color: #8210da; font-family: Arial; font-size: 16pt;">Topic 9: <span style="background: none repeat scroll 0% 0% #f1d5d5; color: #8210da; font-family: Arial; font-size: 16pt;">SLA: Service Level Agreement

<span style="background: none repeat scroll 0% 0% #f1d5d5; color: #8210da; font-family: Arial; font-size: 16pt;">Md. Abu Sayem Shahadat (ID:101-25-156)

 * Software houses must create a whole new kind of service level agreement (SLA) if they start selling their software as a service rather than a product, according to a body, which represents software developers.**
 * Software developers are increasingly offering their products as an on-demand service with full support rather than simply as boxed products.**
 * "For software as a service (SaaS) providers, the SLA is used to set realistic expectations for their customers. "The SLA clearly defines the service level commitments established by the software provider and identifies their obligations to the customer and methods of reasonable compensation should these obligations not be met.**
 * SLA introduces a new level of accountability from the software provider and a means to measure and monitor service performance. Also train up the client demand on client requirements.**
 * Customers and providers alike must take care in the details of an SLA as it is a legally binding agreement. One key area is in credits. Penalties for worse service than is agreed in an SLA generally come in the form of credits, which are applied as discounts in the next period of service.**
 * "Because of the legal nature of the SLA, it is important to carefully draft the limits to the remedy for credits for both parties to the agreement.**
 * "The credit calculation must unambiguously cover the different types of failure and should clearly define compensation due for extended single outages or cumulative periods of downtime within a fixed period.**
 * "Unless these credits have been unmistakably defined, there is a huge risk of misinterpretation for credits due. In addition, the SLA must outline the maximum credit that will be available for any period.**
 * It should also be made clear in what circumstances no credits will accrue. This can be for unexpected circumstances out of the control of either party, known as "force majeure", for changes ordered by the customer outside of the original agreement, and for scheduled downtime's.**
 * The agreement should detail what hours the provider is available and when it is not, as well as the expected availability of the provided service, expressed as a percentage. The customer should agree with the service provider what kind of failures count as chronic, and how penalties will apply.**

**%%%%%%% Comment's or question's Section %%%%%%%**
 * Name/ID: Aliullah Bhuiyan.ID:093-25-138 **
 * Question ** **:**

**Would you please mention the key points which should be included in the Service Level Agreement ?**

 * Thank You**
 * Name/ID: Aliullah Bhuiyan.ID:093-25-138 **


 * Name/ID: Muhammad Pasha (102-25-165) **


 * __Question:__**


 * Dear Members, you put a very nice explanation about the SLA. But, i could not understand some of your points,**
 * Therefore, I need some more information.**


 * Would you please mention the key points (bullets) which should be included in the Service Level Agreement (SLA)?**


 * Thank U**

Comment or question by other group member: **%%%%%%% Comment's or question's Section %%%%%%%**
 * Name/ID: Muhammad Pasha (102-25-165) **

Response by one member of this group:

Name/ID: ** Abdur Rahman Bhuiyan [ID:093-25-140] **

Thank you Mr. Aliullah Bhuiyan and Mr.Muhammad Pasha for your nice question. You saw that in my SLA document I have focus on the three key points which are


 * Service contact - What ** hours the provider is available and when it is not, maximum down time etc. **


 * Training – For new employees and for any extended services ** demand on client requirements. **


 * Mode of operation - ** credits for both parties to the agreement. **

=
=======================================================================================

=
====================================================================================== **%%%%%%% Comment's or question's Section %%%%%%%**
 * Md. Kamrul Hasan Chayon ID-> 101-25-142 **
 * Question ** **:**

**Well described but key Points is needed?** After software delivery a new service/module need to add as software-modification how it will affect the SLA?

 * Thank You**

=
==========================================================================

=
=======================================================================================

=
After software delivery if new service implemented we need to change the SLA approved by the Vendor and the relevant Organization executive. The amendment of the agreement would take place through an addendum to this agreement and the recording of that addendum in an //Appendix// of this agreement. There will be an opportunity on a half yearly basis to make adjustments to this SLA. The Vendor and the Organization should work together to make changes at that time.======


 * Md. Kamrul Hasan Chayon ID-> 101-25-142 **

=
=================================================================================================== Comment or question by other group member:


 * Chowdhury Tanvir Jalil (ID No:092-25-129 **)
 * Question ** **:**

Does SLA contain any policy or guideline about the relationship between the software provider and the client after delivering the software? -'; Response by one member of this group:

Name/ID: ** Abdur Rahman Bhuiyan [ID:093-25-140] **

Thank you Mr. Chowdhury Tanvir Jalil for your good question. In my SLA documents you saw that ** SLA **** introduces a new level **
 * of **** accountability **** from the software provider and a means to measure and monitor service performance. Also train up the client **
 * demand on client requirements. **
 * This is the day to day ** relationship between the software provider and the client after delivering the software.