2. CONTENTS
⢠General Introduction (Background of Study)
⢠Statement of Problem
⢠Aim of the Study
⢠Objectives of the Study
⢠Scope / Limitation of the Study
⢠Significance of the Study
⢠Literature Review
i. Collaborative Systems
ii. CSCW
iii. Groupware Development
⢠Methodology Used
⢠Why Collaboration
⢠Non-collaborative work
⢠Basic Workflow of The Application
⢠Attributes of the application
⢠Distributed Capabilities
⢠Expected Result
⢠Conclusion
3. GENERAL INTRODUCTION
The distribution of Software Engineering teams across multiple
locations especially in large software projects and the need to work
collectively requires special attention which is the premise upon
which these proposal seeks to address.
Software engineers must be able to communicate independently of
their location and communication devices, coordinating efforts and
creating a shared knowledge of the information and each otherâs
work. Hence, the adoption of collaborative systems.
4. GENERAL INTRODUCTION CONTD.
We canât run the modern world without software. National infrastructures and
utilities are controlled by computer-based systems. Industrial manufacturing
and distribution is completely computerized, as is the financial system.
Entertainment, including the music industry, computer games, and film and
television, is software intensive.
Therefore, software development is essential for the functioning of national
and international societies. Software systems are abstract. They are not
constrained by the properties of materials, governed by physical laws, or by
manufacturing processes. This simplifies software engineering, as there are no
natural limits to the potential of software.
5. GENERAL INTRODUCTION CONTD.
The increasing complexity of applications has necessitated the use of teams to
develop software because it is infeasible for individuals to develop large
software systems with appropriate expediency. The development of large
systems in an efficient and timely manner requires a team effort, and the more
complicated the problem, the larger the team needed to solve it, hence the need
for collaborative systems.
As humans, we have several limitations that affect our ability to create almost
any piece of software, we are slow and error-prone. To solve this problem, we
have to work in a group as a means to finish projects on time and within
budget, therefore collaboration is sacrosanct.
6. STATEMENT OF PROBLEM
The current operations of software engineers and software
development organizations today are inadequate due to lack of
collaboration facilities between members of staffs. Single users
applications employed are inaccurate and requires time, space
and extra cost before completing a single software development
project.
Some of the Problems plaguing software developers and
organizations that designs softwareâs includes:
1. Increased administrative overhead.
2. Internal pressure for increased effectiveness.
3. Desire by workers for more reward and less stress.
7. AIM OF THE STUDY
The aim of this research is to design and Integrate in a single
application environment a rationally chosen set of features,
capable of supporting collaborative activities between software
engineers, that will reduced administrative costs and lead to
improve collaboration.
8. OBJECTIVES OF THE STUDY
The work seeks to achieve the following objectives:
1. To design an architecture that will enable easy
collaboration with features capable of aiding the teamwork
of software developers.
2. To be able to establish communication between team
members separated by distance.
3. To enable instant collaboration, managing of multiple
revisions and tracking of changes within a project.
9. SCOPE / LIMITATIONS OF THE STUDY
This work will focus on research and development of
collaborative software in the area of software engineering.
The limitations will be:
1. Difficulty in gathering requirement
2. Design tradeoffs
3. Finding appropriate development platform to build the
proposed application.
10. SIGNIFICANCE OF THE STUDY
The proposed application would be useful for:
a) Minimizing the time and effort spent by software engineers on using
separate software products for having access to collaboration
features; being accessible anytime and anywhere.
b) Domain-specific expertise will be localized though geographically
distributed with the developed application.
c) The application will save costs and manpower in software
development while maximizing productivity.
d) Manage the interaction between developers better.
11. LITERATURE REVIEW
A brief history of software engineering with respect to collaborative software
development as well as reviewing relevant research work conducted by
researchers was carried out.
The notion of software engineeringâ was first proposed in 1968 at a conference
held to discuss what was then called the âsoftware crisisâ (Naur and Randell,
1969). It became clear that individual approaches to program development did
not scale up to large and complex software systems.
Throughout the 1970s and 1980s, a variety of new software engineering
techniques and methods were developed, such as structured programming,
information hiding and object-oriented development. Tools and standard
notations were developed and are now extensively used, one of such is
collaborative technologies.
12. COLLABORATIVE SYSTEMS
Collaborative Systems refers to software systems intended to support group
interaction and collaborative teamwork. A number of environments have been
developed that provide some of the basic elements of Collaborative
functionality. The review will be selective rather than exhaustive, since it is
intended primarily to representatively illustrate the kind of systems available.
Nunamaker (1999) establish that collaborative Systems are software systems
intended to support group interaction and collaborative teamwork. In the
same vain Swigger & Shin, (2000) noted that collaborative systems are
designed to enable geographically separated users to work together on a large
programming project
13. COLLABORATIVE SYSTEMS
Nosek (1998) research found that teams outperformed the individual
programmers, enjoyed the problem-solving process more, and had greater
confidence in their solutions. While learning to develop software, beginning
programmers often encounter difficulty understanding basic problem solving
concepts.
Finnegan & Mahony, (2006) affirm that, groups appear to be able to deal with
complex tasks more effectively than individuals simply because groups have a
larger range of skills and abilities.
Samarah (2006) Collaborative technologies make it possible for organizations
to quickly bring together remote workers into virtual teams to perform a
variety of tasks. It involves working with a team to create a product or service.
14. COMPUTER SUPPORTED COOPERATIVE WORK
Computer Supported Collaborative Work (CSCW) is a community of
behavioral researchers and system builders at the intersection of collaborative
behaviors and technology. The collaboration can involve a team, it can be
within or between organizations, or it can involve an online community that
spans the globe.
Olson and Olson (2012) along with the increase in capability, declining
technology prices enabled researchers to get ahead of the curve. Collaborators
have been developed to support large-scale multisite efforts, primarily in
scientific research, engineering, and education.
Greif and Cashman (1984) coined the term âCSCWâ at a workshop attended by
individuals interested in using technology to support people in their work.
CSCW is also referred to as âsoftware for groups of peopleâ. Rapid technology
change has been a driving force in this field.
15. GROUPWARE DEVELOPMENT
Groupware was first used in 1982 in a paper by Johnson-Lentz in
the context of computer-mediated communication (CMC) systems.
Defined by Ellis et al (2012), as âcomputer-based systems that
support groups of people engaged in a common task and that
provide an interface to a shared environmentâ
Groupware is a Technology that allow dynamic groups to interact
across time and space (Grudin, 1994). Typically, these groups are
small, project-oriented and have important tasks and tight
deadlines to deliver expected results.
16. ASPECT OF GROUPWARE
ď Common task / goal
ď Interface to a shared environment
ď Technology systematically reduces interaction costs and extends
global reach
ď In addition, because there are more than two users, additional
implications are:
Division of labor, explicit role assignment
Awareness of the other users who are interacting within the
shared environment (since they are often not Face to face)
17. METHODLOGY
Methodology in research is a framework that is used to structure, plan, and
control the process of developing an information system. This work will adopt
waterfall model, requirement will be gathered, design will be made both
architectural and graphical, the system will then be developed, test, evaluated
and deployed.
WHY WATERFALL?
It support extensive documentation
Its allow for change tracking
18. WHY COLLABORATION?
Sinha et al.(2006) Collaboration in Software Engineering is a requisite for
software engineers to coordinate their efforts and develop a shared
understanding of a project, over the entire development process. Software is a
Team Sport.
How should developers be working?
Collaboration - Working with others leads to more ideas and creativity
â˘Tracking Changes - Using revision control software, tracking changes to code
and keeping a log makes it easier to revert to older versions of the code, and
keep track of work
â˘Documentation - Creating documentation and putting comments in code
makes the code easier to understand and edit, and makes it easier to share
code with others
19. NON-COLLABORATIVE WORK
A Developer Works Alone :
Work Goes Unchecked By Others
If The Owner Leaves, Nobody Knows How The Software Works
There Are No Ideas Contributed By Others During Development
A developer doesn't log changes:
ďś Hard to revert to a previous version of the code
ďś Can't remember what they did last week
ďś Can't tell why a specific change was made
A developer doesn't create documentation:
ď Hard for others to adopt code
ď Hard for backup code owners to fix bugs and/or run code
ď Hard to share code with others
20. BASIC WORKFLOW OF THE APPLICATION
⢠Edit Files
⢠Add them to be versioned (staging commits)
⢠Review changes
⢠Commit changes to the repository.
Edit
Stage/
Review
Commit Push
21. ATTRIBUTES OF THE APPLICATION
ď Distributed Version Control System
ď Directory Content Management System
ď Active content tracker
ď Tree history storage system
22. DISTRIBUTED CAPABILITIES
ď Everything is done offline
ď Everyone has the complete history
ď No central authority
ď Changes can be shared without a server
24. EXPECTED RESULT
ď Perform quickly and efficiently
ď Facilitate distributed development
ď Complete repositories
ď Enforce accountability
ď Scale to handle thousands of developers
25. CONCLUSION
This work seeks to advocate improved software
development and project management techniques,
including collaborative software development.
Who does this apply to?
â˘Universities
â˘Government
â˘Private sector
â˘Any software developer
26. CONCLUSION
Business models must adapt to survive in todayâs business
environment. Openness fosters adaptability and flexibility. Letting
go of control and loosening the reins on the development
environment leads to greater innovation and business value.
Programming in the large must become programming in the VERY
large over internet protocols and standards
Fostering collaboration in projects can speed development and
ultimately, result in greater advances for the organizations. Even
for proprietary software. Commercial, open source and hybrid
software models all deliver distinct value to the marketplace. They
are leading to the emergence of new software business models such
as collaborative system.
Editor's Notes
Git is a distributed version control system.
Given Gitâs nature you can even share changes in a peer-to âpeer nature.
This does not happen often but Git does enable this ability. If your server is offline for some reason your team can still work.
Since everyone on the team has a complete copy of the repository you can do things like this.
But no one wants to keep track of changes this way.
Given Gitâs nature you can even share changes in a peer-to âpeer nature.
This does not happen often but Git does enable this ability. If your server is offline for some reason your team can still work.
Given Gitâs nature you can even share changes in a peer-to âpeer nature.
This does not happen often but Git does enable this ability. If your server is offline for some reason your team can still work.
Given Gitâs nature you can even share changes in a peer-to âpeer nature.
This does not happen often but Git does enable this ability. If your server is offline for some reason your team can still work.