How to Troubleshoot Apps for the Modern Connected Worker
Project plan
1. SENIOR PROJECT 2007-2008
(Project plan of the ekoSign project)
2. Project Plan
Software Methodology, Model,
Schedule, Roles and Responsibilities
Project team members
Hüseyin Çakır, Mehmet Mesut Özışık, Yılmaz Kaya
Abstract:This paper describes the planning phase of the project. First part defines and lists reasons for
selecting the methodology. Than modeling technique that is selected to provide a formal basis for
understanding project steps is explained and in the second part there is a project schedule that is presented
by a modern software analysis tools also including appropriate roles and responsibilities according to the
group actors.
Keywords:Software methodology, model, schedule, roles and responsibilities.
http://groups.google.com/group/digitalsignature
digitalsignature@googlegroups.com
PRINT DATE: 05/06/08
1
2. 2.1 Introduction
This documentation is related with the inception phase of the project. The goals of this phase is to
establish a preliminary project schedule and project risks associated with the project. Figure 2.1
shows the steps of the unified process and which step the project plan paper belongs to.
Inception
Elaboration
Construction
Transition
1.Introduction
2.Project Plan
Figure 2.1 Steps of Unified Process.
2.2 Software Methodology
A methodology is a general term applied to a variety of structured, organized processes that may be
repeatably carried out to produce software [1]. Using a methodology is important in developing
software because choosing right methodology results in fewer defects and, therefore, ultimately
provides shorter delivery times and better value.
The Unified Process (UP) selected as a methodology throughout this project since the UP combines
commonly accepted best practices, such as an iterative life cycle and risk-driven development, into
a cohesive and well-documented description. UP concept based on dividing project into hundreds of
small tasks to accomplish a larger goal.
Each iteration includes its own requirements analysis, design, implementation, and testing activities.
The iterative life cycle is based on the successive enlargement and refinement of a system through
multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable
system. The system grows incrementally over time, iteration by iteration, and thus this approach is
also known as iterative and incremental development. In this project the iterative approach which is
provided by UP will be used as revising and reworking some of phases is highly needed and this
approach enables development of a piece by growing, improving, and refining over several time
periods [2].
•
Iteration: A time-bound minor milestone within a phase.
A typical iterative development consists of four iterations; inception, elaboration, construction, and
transition (Figure 2.2).
•
•
•
•
Inception: Identifies project scope, risks, and requirements at a high level (Planning),
Elaboration: Working architecture that emphasis risks and captures the non-functional
requirements (Analyze),
Construction: Filling in code produced from analysis, design, implementation, and testing of
the functional requirements (Implementing),
Transition: Delivers the system into it's operating environment (Delivery).
2
3. development cycle
inception
elaboration
construction
transition
Figure 2.2 Iterations in the UP.
2.3 Software Modeling
The Unified Modeling Language (UML) is going to be used in this project for specifying,
visualizing, constructing, and documenting the artifacts of software systems, as well as representing
business modelings.
The UML represents a collection of best engineering practices that have proven successful in the
modeling of large and complex systems [3].
The primary goals in the design of the UML were as follow:
•
•
•
•
•
•
provide users a ready-to-use, expressive visual modeling language so they can develop and
exchange meaningful models,
provide extensibility and specialization mechanisms to extend the core concepts,
be independent of particular programming languages and development processes,
provide a formal basis for understanding the modeling language,
support higher-level development concepts such as collaborations, frameworks, patterns, and
components,
integrate best practices [4].
The reason of selecting UML in this project is to:
•
•
•
•
•
•
make plans for constructing our software,
visualize the software in multiple dimensions and levels of detail,
use unified and universal tool for modeling project steps,
use traceability that UML provides via tools,
model XML document flows and XML signature concepts,
model incremental development and re-development which is critical for us as in this project
the UP methodology will be used.
The use case modeling is a kind of UML representations which will be applied to analyze the
functional requirements of the project. Use case diagram of the project was developed in Microsoft
Visio 2003 modeling software (Figure2.3).
3
4. Figure 2.3 Use Case diagram for the ekoSign Project.
2.4 Project Schedule
This project's Gantt Chart includes all of the detailed project schedules, including the release date.
The team determined the release date after negotiating. Although features, resources, and release
date can be modified, a fixed release date will help the team prioritize features, assess risks, and
plan adequately. The key concept to success of this project is finding the right balance between
resources, deployment date, and features.
The following figure shows this project's schedule which was developed in Microsoft Project
Professional 2003 (Figure 2.4).
4
5. Figure 2.4 Gantt Chart Diagram of the Project.
The deadline of the project is 12.05.2008 and total project duration is 179 days. The main phases of
the project are; Management and Planning (78 days), Analysis (27 days), Design (21 days),
Implementation (20 days) and Testing & Deployment (6 days).
Network diagrams are used by the project team to show the sequence of development activities and
the interrelationship of each task with another in the project (Figure 2.5).
5
6. Figure 2.5 Network Diagram of the Project with Main Tasks.
2.5 Project Staffing
Staffing is one of the most important elements to success this project. Once project team have
defined the project and clear about at least some of the project's initial tasks, staffing needs must be
construct so we tried to analyze the type of staff that the project needs and than individuals
assigned to project.
Project team composed of three individuals, and has two main actors; project staff and project
leader as it mentioned before in the use case (Figure 2.3). Project leader is an actor responsible for
planning the weekly agenda of the project, arranging works to the project team members and also
responsible for selecting deadlines for the arrival of the iterations and updating project outcomes
and outputs. Project staff is responsible for researching, understanding project related concepts and
involving in project implementation.
Project staff actor is also responsible for documentation and applying the IEEE documentation
standards to the project documents and reporting iterations that team follows according to the
software methodology that is chosen.
6
7. PROJECT TEAM MEMBERS
Hüseyin Çakır
huse.ckr@gmail.com
Mehmet Mesut Özışık
mmesutozisik@gmail.com
Yılmaz Kaya
yilmaz.kaya12@gmail.com
Table 2.1 Project Team Members.
Mehmet Mesut Özışık is the leader of the ekoSign project. But in each iteration leader will be
changed according to the knowledge of the individuals (Table 2.2).
PROJECT LEADER
Mehmet Mesut Özışık
DOCUMENTATION &
REPORTS
Hüseyin Çakır
STEPS
LEADER
TEAM MEMBERS
Management and planning
Yılmaz Kaya
Mehmet Mesut Özışık
Hüseyin Çakır
Analysis
Hüseyin Çakır
Mehmet Mesut Özışık
Yılmaz Kaya
Design
Hüseyin Çakır
Mehmet Mesut Özışık
Yılmaz Kaya
Implementation
Mehmet Mesut Özışık
Yılmaz Kaya
Hüseyin Çakır
Testing
Yılmaz Kaya
Mehmet Mesut Özışık
Hüseyin Çakır
Deployment
Mehmet Mesut Özışık
Yılmaz Kaya
Hüseyin Çakır
Table 2.2 Project Steps & Staffing
.
We use Google Groups to securely manage our group messaging and discussion archives in order to
protect project privacy.
PROJECT GROUP:
http://groups.google.com/group/digitalsignature
digitalsignature@googlegroups.com
7
8. 2.6 Project Risks
A risk is a potential problem-it might happen, it might not. But, regardless of the outcome, it's a
good idea to identify it, assess probability of occurrence, estimate its impact, and establish a
contingency plan should the problem actually occur. Risk analysis and management are a series of
steps that help a software team to understand and manage uncertainty [5].
Software projects generally fail to be delivered on time, within budget, and achieve its objectives.
One area of concentration in software project management that has developed to solve these
problems is Risk Management, which attempts to assess and then control the risks that precipitate
them. Measures and the metrics, allow the managers to determine the status of their programs, track
the project's progress against the plan, measure the quality of the product being developed, and
become aware of potential problems.
The risks associated with this project are:
•
incomplete understanding of the requirements,
•
learning curve for the new technologies included with the project,
•
not achieving project objectives that are defined in the planning phase,
•
team inexperienced with usage of XML signatures.
8
9. 2.7 References
[1]. A. Gupta., Y.A. Tung, J.R. Marsten, “Digital signature:use and modification to achieve success
in next generational e-business processes”, Science Direct, p.571, June 2003. [Online].
Available:http://www.sciencedirect.com. [Accessed October 17, 2007].
[2].Craig Larman, “Iterative development and the unified process”, in Applying Uml And Patterns,
2nd edition, pp.13-25.
[3].Object Management Group, “Getting started with UML”, [Online]. Available:
http://www.uml.org [Accessed October 17, 2007].
[4].Object Management Group, “Introduction to UML”, [Online]. Available: http://www.uml.org
[Accessed October 17, 2007].
[5]. Roger S. Pressman, “Risk Management”, in Software Engineering, 6th edition, pp. 730-740.
9