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

Name: Ahammad Fekri

ID: 102-25-156

Topic 1: TIME AND BUDGET
*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

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

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..

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

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

Question:
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)?

---

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...

==================================================================
Sample Content for the topic “Tools” of the documentation
By:

• Muhammad Ashik Iqbal (092-25-127)
• Muhammed Samsuddoha Alam (093-25-139)

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

4. Tools Required for the System
Platform:
Server:

• Microsoft Windows Server 2008

Client:

• Microsoft Windows XP/Vista/7

Hardware:
Server:

• Intel Xeon Processor 3000 Series
• 32 GB RAM
• 2 x 5TB Storage
• DVD-RW Drive

Client:

• Intel Core i5
• 2GB RAM
• 500GB HDD
• DVD-RW Drive
• Laser Printer

Systems:
Server:

• IIS 7.0
• DotNET Framework 4.0
• Crystal Report 2010
• Microsoft Team Foundation Server
• SharePoint Server 2010

Client:

• Microsoft Office 2010
• Internet Explorer 8.0
• Mozilla Fire Fox 3.x
• DotNET Framework 4.0
• Microsoft Silverlight 4.0

Database:
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".

with regards,

Muhammed Samsuddoha Alam

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.

---

---

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

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

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.
Time periods: A progress report usually summarizes work within each of the following:

• 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

Question:
What about the schedule of preparing progress report? Is it fixed or prepared by user requirement?
REPLIED BY: Md. Kamrul Hasan CHAYON 101-25-142
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.


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

Comment or question by other group member: SLA

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

Question:

Nice work done guys. But i just wanted to know do you want to introduce any reporting tools?

If any changes occur in the system what will be the affect in your general reporting schedule?

Replied By: Md. Kamrul Hasan CHAYON, 101-25-142
ANS:

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.

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




::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

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

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

Chapter 06

Modification

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

1.Modification:

Modification means update or upgrade of software. By prototyping we can easily change,

update clients demand.Change made after client requirements which will be specific fields.

New report or output generated by client’s specification.Update module which will be take

effect on output by client need. Upgrade software by add or delete module which will add

extra facilities or requirements that clients need.

Sometimes there is new facilities add into a company or a new work specification added

to the system then there is a update required for software. However if there is any other

requirement that not match to the system that the client need then there is a modification

of the software need to update software.

2.Management:

A. We need to be aware of the potential for scope creep, which is an odd phenomenon

in which some stakeholders lose perspective and begin to make requests that were

never part of the original plan.We can recognize scope creep when we begin people

express expectations that certain functionality that we never planned for ought to be

included.

B. With project Management experience, we will start to notice the types of activities

that precipitate requests for changes. For example, during project meetings, certain

stakeholders may talk about functionality that wasn’t included in the scope. They

may talk about these extras as if adding them is no big deal. They may even act as

if everyone knew that this functionality was expected all along.

C. At first we consider, the problem is an error or enhancement of the system. If we
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.

3.Version:

Version management is not essential for the modification stage because of the system

UAT running.That’s why version will be remaining unchanged. But enhance the system

then version will be changed.If a client wants to add some contents very newly or

want to change some parts in current systems after agreements time, it will be

included with a new version and with new agreements.Clients should be pay extra

money for new works.

4.Documents:

Documentation for the modification is not also needed because of all the procedure and

specification clarified in SRS (System Requirement Specification) by the Stakeholder and

Development team.If Stakeholder wants to enhance any part of the system then the

documentation is needed.

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

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 by Khaled Mahmud, ID# 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)

ANSWERED BY

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.

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

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

If you are thinking otherwise then lets define your points clearly.

QUESTION BY MUHAMMED SAMSUDDOHA ALAM, ID#093-25-139

ANSWERED BY

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?

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

ANSWERED BY

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...?

ANSWERED BY

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.

Phases of software development in which the software is tested in the "real world" by the intended audience
- Beta testing
- Application testing and
- End user testing.
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.


User Acceptance Testing – Prerequisites:
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.

User Acceptance Testing – What to Test?
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.

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

User Acceptance Testing – How to Test?
The user acceptance testing is usually a black box type of testing. 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.

However, it is useful if the User acceptance Testing is carried out in an environment that closely resembles the real world or production environment.

The steps taken for User Acceptance Testing typically involve one or more of the following:
.......1) User Acceptance Test (UAT) Planning
.......2) Designing UA Test Cases
.......3) Selecting a Team that would execute the (UAT) Test Cases
.......4) Executing Test Cases
.......5) Documenting the Defects found during UAT
.......6) Resolving the issues/Bug Fixing
.......7) Sign Off

User Acceptance Test Process Flow


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:

• Validating system set-up for transactions and user access
• Confirming system use in performing business processes
• Verifying performance in critical business scenarios
• Confirming integrity of converted and additional data
• Assessment and sign off of go-live readiness

User Acceptance Test (UAT) Planning:
As always the Planning Process is 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.

Designing UA Test Cases:
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.

Each User Acceptance Test Case describes in a simple language the precise steps to be taken to test something.

The Business Analysts and the Project Team review the User Acceptance Test Cases.

Selecting a Team that would execute the (UAT) Test Cases:
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.

Executing Test Cases:

The Testing Team executes the Test Cases and may additional perform random Tests relevant to them

Documenting the Defects found during UAT:
The Team logs their comments and any defects or issues found during testing.

Resolving the issues/Bug Fixing:
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.

Sign Off:
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.

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]

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

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
Answer:
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.

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

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

Question:

---

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

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

###############################################################################


Topic 2: PROCESS :
SCOPE OF WORKS & OVERVIEW


prepared by :

MUHAMMAD PASHA (102-25-165)

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

Software development process

Activities and steps

Requirements · Specification Architecture · Design Implementation · Testing Deployment · Maintenance

Methodologies

Agile · Cleanroom · Iterative · RAD · RUP · Spiral Waterfall · Lean V-Model · TDD

Supporting disciplines

Configuration management Documentation Quality assurance (SQA) Project management User experience design

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)

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

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
Answer:
As we can see the Process includes SCOPE OF WORKS & OVERVIEW 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 that 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:

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

##############################################################################################


Topic 3:

Techniques:

Prepared by: Chowdhury Tanvir Jalil (ID:092-25-129)
Sazib Chowdhury (ID:092-25-130)


Introduction
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 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
Thick methodologies are RUP, SSADM and PRINCE2. XP, SCRUM and Crystal Clear are considered as thin methodologies.
Rational Unified Process (RUP)
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.
SSADM
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.
PRINCE2
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.
Extreme Programming (XP)
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.
Principles of XP
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
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:
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
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.
Project Management Body of Knowledge (PMBOK)
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.
Constructive Cost Model (COCOMO)
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.
Milestone Trend Analysis (MTA)
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.
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.

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.

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

Topic 9:
SLA: Service Level Agreement

Prepared by: Abdur Rahman Bhuiyan (ID:093-25-140)

And

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:

Dear Friends, your description is nice about Service Level Agreement.But, i am confused

of your overall description procedure.

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:
Name/ID: Muhammad Pasha (102-25-165)
%%%%%%% Comment's or question's Section %%%%%%%

---

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.

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

Response by one member of this group: Name/ID: Md. Abu Sayem Shahadat [ID:101-25-156] Thank you Pasha for your question. Yes, in our documentation we missed out the key points of the SLA.

Below is chart of SLA key points from our point of view.

SLA Key Points

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

%%%%%%% 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

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

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

Response by one member of this group:

Name/ID: Md. Abu Sayem Shahadat [ID:101-25-156]

Thanks Choyan

Firstly Key Points are added above....

Secondly

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.