Agile Project Development

Table of Contents

Execute Summary

Introduction

1. Why an agile approach should be used to develop this Aegis system?

1.1. Four main values in Agile Alliance

1.1.1. Individuals and interactions over processes and tools

1.1.2. Working software over comprehensive documentation

1.1.3. Customer collaboration over contract negotiation

1.1.4. Responding to change over following a plan

1.2. Twelve principles in Agile Manifesto

Ensuring customer satisfaction through pre-continuing delivery of value-added software is our top priority.

Calling for changes that are delayed in the development. The agile process makes changes to the competitive advantages of customers.

Always get a working program of up to several months to more than a month for your short-term period.

Business stakeholders and developers need to work daily throughout the project.

Constructing projects around motivated individuals. Trust them to get the job they need and the support they need.

A conversation in face-to-face with a more efficient and productive method that provides information to a development team.

Work software is the first step in progress.

Sustainable development is promoted by agile process. Customers, developers and users must be constantly maintained.

Continuous focus on technical excellence and good creative work enhances agility.

Simplicity.

The best architects, needs and plans are emerging from self-organized groups.

It reflects how it works more effectively over time, at specific times.

1.3. Scrum of Scrum

1.4. Scrum vs Kanban

1.5. Scrum vs DSDM (Dynamic Systems Development Method)

2. Stakeholders of the Aegis System and their roles within Scrum Agile Project Framework.

3. Moscow technique for prioritization

3.1. Why Moscow technique is used for Aegis system

3.1.1 Must or Must Have

3.1.2 Should or Should Have

3.1.3 Could or Could Have

3.1.4 Won’t or Won’t Have

3.2 Work Breakdown Structure for Aegis System

3.3 Effectiveness of the Moscow method to Aegis project

3.4 Use Case diagram for Organizing Management Services

3.5 Use Case diagram for Situation Management

3.6 Use Case diagram for Mapping and Geo Location

3.7 Use Case diagram for Resource management

4. User Stories for the MUST have requirements

5. Prototypes for two stories

6. Iterative Development for the prototype

6.1. Description of the iterative development

6.2. Backlog Grooming

6.3. Agile Development Sprint Planning/ time-box Planning

6.4. Elaboration

6.5. Sprint Review Meeting

6.6. Sprint Retrospective

6.7. Change Management

6.7. Final prototype after changes

7. A first cut class diagram showing only the class names and attributes and relationships that will form the basis of the database for the information system that will be developed.

8. Conclusion

References

List of Figures

Figure 1: Agile Lifecycle

Figure 2: Moscow Methods

Figure 3: Work Breakdown Structure for Aegis System

Figure 4: Moscow Analysis

Figure 5: Use Case diagram for Organizing Management Services

Figure 6: Use Case diagram for Situation Management

Figure 7: Use Case diagram for Mapping and Geo Location

Figure 8:Use Case diagram for Resource management

Figure 9: Prototype for allocate resources

Figure 10: Prototype for update profiles

Figure 11: Final prototype after changes

Figure 12: Class Diagram for Aegis system

List of Tables

No table of figures entries found.

Execute Summary

It is important to develop software that has gained importance in the industry because of human issues and the benefits of investing. This article examines the Scrum agile software project management model based on the model of software project management in a disaster relief coordination system. (Adapting and Using Scrum in a Software Research and Development, 2018).

At present, the software development industry has been abandoned for the development of agile software from traditional development. In this article the conceptual framework has been proposed. The main emphasis of this framework is the need for the engineering process to be more effective and to add it to reverse. (Anon, 2018).

This report highlights the features of the Agile technique recommended by management for the awareness and conviction of audiences to follow. The report concludes that the main advantages of implementing the SCRUM framework. The chosen Agile development model was much more than a reflection. Therefore, a recommendation for the SCRUM framework is justified by its business value driven by its dynamic nature. (Anon, 2018).

Introduction

Scrum is a widely used, lightweight and powerful project management framework to control and control all significant and scale projects. Agile’s popularity in the software development community has increased in Scrum. Its simplicity, productivity and other agile processes can act as an embedding process for various engineering applications. The Scrum methodology, the “Product Owner” works closely with the team to identify and prioritize system performance in the form of “Product Backlog”. Product Backlog consists of features, error correction, non-functional requirements, etc. whatever, any need to do an efficient software system. With generic priorities, Product Owner signs cross-functional teams to provide a potential tool for software sequential purposes. Sprint’s product backlog is committed, and Sprint cannot add additional functions besides the team. If Product Backlog is analyzed and provided, Sprint is required, then the next Sprint is selected for the following operations. (VersionOne, 2018).

Software development firms are more interested in Agile, whose focus is customer relationship management, single value, and adaptation to change. This methodology has been developed due to the increase in productivity of several software development projects. Choosing the right software for the development of software is only a small task and ensures the success of the project. However, the Agile methodology has been taken into account by software companies and has provided the basis for productivity growth. The first movement to develop the software development section introduced a disciplinary approach to the development of software, introducing the method for business introduction, more efficient process and forecasting. Agile Manifesto defined an appropriate methodology at a meeting of the software development process. This statement is a simple and concise statement attempting to change the conventional lens used for software development. (Adapting and Using Scrum in a Software Research and Development, 2018).

In the Scrum format, we propose a project progress through a series of sprints. Following the AGILE method, Sprints are timeboxed to no more than one month, often over a period of two weeks. The Scrum methodology appears at the beginning of Sprints at a Planning Meeting, and how many members of the group can find the items they can commit themselves to, and create a Sprint backlog – a list of tasks performed in Sprint. During the Agile Scrum Sprint, the Scrum team takes a small group of symbolic and insightful activities. Ultimately, these features are carried out in a symbolic, experimental and evolved product or system. (Cohn, 2018).

1.      Why an agile approach should be used to develop this Aegis system?

Disaster management projects are best suited for agile project management. At the meanwhile, while implementing changeable prototype, procurement of information is a mandatory need for disasters. Good productive information is needed to minimize the impact of disasters on an effective coordinated response. The poor quality of the information blamed on various problems in recent large-scale disaster response such as the 9/11 terror attack and the 2004 Asian tsunami. A quick and accurate information is needed for an effective solution altogether. Using the appropriate methodology, guidelines for advanced optimization levels will be guided and information will be available in its life cycle. Assisted response in instant and effective response to changes. Focus on people and their interaction with powerful statements, processes and tools. Instead of the true documentation, instead of customer contract rather than customer relationship, rather than a live software and a single design for the entire life cycle. The statement is well accomplished considering the material for effective disaster management. (Managing Task Uncertainty with the Agile Project Methodology, 2018).

The way of guiding and planning a project can be taken as agile software development. Figure 1 shows that the appropriate life cycle started with the parties in order to determine what the possible outcomes for the product. The owner of the product, stimulates the input of stakeholders to write epics that require the breakdown of small work pieces. When an epic break into stories, the story is maintained and prioritized in a backlog. Agile Software Development (ASD) is always the interconnected interactive inline cycles. (A SYSTEMATIC LITERATURE REVIEW ON AGILE PROJECT, 2018).

Figure 1: Agile Lifecycle

This section presents the main concepts and methods of agile software development process that lead readers to understand the concepts conceived by this section. As a reaction to plan driven bureaucracy of methodology, there are many things to follow in order to slow down the overall step of software development. Therefore, the agile methods adopted for programming and software processes have become more numerous than predictions.

The Agile software development methodology is characterized by the following attributes: incremental, co- cooperative, straightforward and adaptive small increments refers to a small software release with a rapid development cycle. A co-operative group and a client are drawn to a close relationship. It clearly means that the method is easy to learn and change, and is sufficiently documented. Finally, the adaptive last-minute responses indicate the ability to respond and respond.

At least planning strategies, and small-scale applications that do not have direct connections to long-term plans break up software applications. Iterations are short time frame which takes from 1 to 4 weeks. Every iteration contains a cross functional team working in all software development circles such as planning, requirement analysis, design, coding, unit testing, and accepting testing. Each of working product are submitted to the stakeholders at the end of each iteration. This type of software project management failure minimizes the risk and allows you to quickly adapt to changes. It does not require sufficient functionality to resolve market issues, but the target is to available release at the end of each iteration. Some iterations may happen to release a product or a new feature. (A SYSTEMATIC LITERATURE REVIEW ON AGILE PROJECT, 2018).

For encouraging the stakeholders to collaborate actively, the agile software development methods which focus on keeping the code simple and testing. Realizing the four valued statements is important if you are to appreciate the concept of the right in the south, but what should be appreciated on the left (presented in red). (Ambysoft.com, 2018). From the right hand, they are not saying those has to do. They further describe what actually expand to from the traditional process. Red color says that Agile values and the other color describes the traditional process. These traditional process main values are related to plan driven project and all of these are concerning of traditional waterfall model. According to the Agile Alliance, there are four main values.

1.1. Four main values in Agile Alliance

1.1.1.      Individuals and interactions over processes and tools

The first value of the Agile Declaration is ” Individuals and interactions over processes and tools.” Conducting the Aegis system’s development process of responding people for business needs makes it easier to esteem more than processes or tools. When developing a process or tool, responding to changes in the team and reducing the chances of meeting customer needs. Communication is an example of the difference between assessing individuals versus process. The names of individuals take place when communication is fluid and happens when a need arises. In the process, communication is needed at the right time with specific content. (Smartsheet, 2018).

1.1.2.      Working software over comprehensive documentation

Historically, spent a huge amount of time to document the products for development and final distribution. For each that could be required following things like technical requirement, technical specifications, interface design documents, technical prospectus, documentation plans, test plans and approvals. This list was broad and caused delays in development on Aegis system. Agile does not eliminate documents, but does not push it into a minority, but gives it to the developer to provide what works to work. A software developer can use strong documentation requirements as sufficient user stories to start building new software like Disaster Relief Coordination System. (Smartsheet, 2018).

Agile Manifesto value documentation, but it’s more appreciated working software.

1.1.3.      Customer collaboration over contract negotiation

The time period for discussing the details of customers and product manager distribution details, the details of the places to be re-discussed. Collaboration is completely different. Customers with development models, such as water model, discuss the requirements for the product, often with a lot of detail, before starting any work. This meant that it was completed after development work, but not during the process. Describes the customer who is engaged in development and collaborative work. This makes it easier for customers to meet their needs. Though customers can use time-consuming methods in timely fashion, it’s easy for the project to easily project as a daily part of a team to meet the business needs of customers. (Smartsheet, 2018).

1.1.4.      Responding to change over following a plan

Preventing traditional software development was considered as an expense as an expense. The aim was to create detailed plans and plans for each element. Generally, focus on the next section of the puzzle with most of the meetings you have on top of priorities and a specific order. (Smartsheet, 2018).

With the Agile, a glossary of shading can prioritize priorities for re-processing and add new features to new features. Agile’s view is that changes are always a project improvement; Changes provide added value. (Smartsheet, 2018).

The goal of ASD (Agile Software Development) is to create working software, not to complete a pre-specified development process. Agile principles make it easier to process software that works. The Agile Manifesto according to Kent Bagk is based on the following twelve principles: (A SYSTEMATIC LITERATURE REVIEW ON AGILE PROJECT, 2018).

1.2. Twelve principles in Agile Manifesto

1.2.1.      Ensuring customer satisfaction through pre-continuing delivery of value-added software is our top priority.

It will be more enjoyable to the customers of the Aegis system when looking for a software on a regular basis rather than waiting period of extended time between the releases.

1.2.2.      Calling for changes that are delayed in the development. The agile process makes changes to the competitive advantages of customers.

Ability to avoid delays when demand or characteristics change.

1.2.3.      Always get a working program of up to several months to more than a month for your short-term period.

Scrum compares this principle in the meantime team operates because of the software’s sprints or iterations function which ensures regular workloads on working Aegis software.

1.2.4.      Business stakeholders and developers need to work daily throughout the project.

When taken with business and technical teams, better decisions are made.

1.2.5.      Constructing projects around motivated individuals. Trust them to get the job they need and the support they need.

Groups who are more interested in improving their skills for the developments of the Aegis system than inferior teams are increasingly expected.

1.2.6.      A conversation in face-to-face with a more efficient and productive method that provides information to a development team.

Communications is more effective when co-located with development groups.

1.2.7.      Work software is the first step in progress.

Providing active software to the consumer of the Aegis system is the ultimate factor in measuring progress.

1.2.8.      Sustainable development is promoted by agile process. Customers, developers and users must be constantly maintained.

The teams can install repetitive and maintenance speeds that allow them deliver working software, and repeat it every release.

1.2.9.      Continuous focus on technical excellence and good creative work enhances agility.

By creating the right skills and good designs, the team can maintain speeds, continuous product development, and change for the Aegis system.

1.2.10.  Simplicity.

The art of maximizing the number of workloads is essential for the Aegis system development.

1.2.11.  The best architects, needs and plans are emerging from self-organized groups.

Communicate with other members and share ideas with quality product groups with decision-making powers, ownership of the team, and other members.

1.2.12.  It reflects how it works more effectively over time, at specific times.

Self-improvement, process improvements, forward-looking skills and techniques are working more efficiently.

1.3. Scrum of Scrum

Aegis project team is a large project team so that scrum of scrum meeting is an important technique in scaling scrum. These meetings allow Aegis teams to discuss their work, to focus especially on areas of overlap and integration. (Cohn, 2018).

Imagine that the Aegis project has seven teams and each with in seven team members. Each of these seven teams need to conduct its own daily scrum meeting.

Each team will be part of a generous gathering by one person. Decide who should decide to send the team. Generally, the selected person should be a technician of a team, such as a database administrator, tester, designer, programmer and someone else. Instead of the product owner or the Scrum Master. Afterwards, the team will represent the teams in the ideal scrum of scrum team.

Scrum of scrum is not selected for participation in the meeting of life. All members of team of an Aegis project should participate. When choosing a task, it’s time to select the best team-based member for understanding and discussing issues during that time. For an example, when we take update worker’s current location task, that would be a task for one team and that would need to be developed as a team. So that, API developments need to be distributed to the person who is more responsible for that and other form level developments need to be given for other team members.

For another example, technical issues or user experiences can arise for problems that arose at the beginning of the Aegis project. Teams will select to send someone to a meeting in each area of each team. Later on, problems can arise in how to deal with problems, so the testers of the Aegis system will increasingly be participating.

According to the number of participants, the scrum of scrum team size depends too. If the number is small, two representatives for each team will be sent as a technical contributor or as stated above, SCRUM Master. If the teams wish, if I’m trying to do this for four teams or less, the group meeting size is eight or fewer.

Scrum of scrum Meetings can be reconciled. Imagine that there are seven meaningful meetings in our IT firm. Each contains a representative from each group of seven of the Aegis project. (as per the example of previous one).

1.4. Scrum vs Kanban

As discussed on above, scrum alliance scrum is used only for completing complex project like Aegis. Scrum is formally designed for software development projects, but it works well for any complex, innovative domain of work. The ability is endless. Scrum frame is very simple. The Scrum highlights the collaboration of teams and provides rules which are a small set. Teamwork has been created to support teams, and it will inevitably be an insuperable challenge. Scrum provides the power to prioritize the requirement of the business. At the same time, the team can have the power for commitment to requirements depending on their capability. Scrum’s work is iterative and incremental and upgrading and is a process of timeboxes. Scrum also emphasizes the response: The team can respond quickly as quickly as possible, and, in fact, the working products that are actually be used. It allows the teams also to retrospect on their performance and improve it in the short cycle. (Scrumalliance.org, 2018).

The Kanban blog says, “Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s ‘just-in-time’ (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.” (Scrumalliance.org, 2018).

Four core principles of the Kanban are: (Scrumalliance.org, 2018).

1. Visualize work
2. Limit work in process
3. Focus on flow
4. Continuously improve

And also, the advantages of the Scrum we can get as, improved credibility with clients, transparency, product stability, high product quality, clients can change requirements and priorities quickly and team members reach sustainable pace. We can say Scrum is the best for Aegis system by following the below statements which are said by David Anderson who is the creator of Kanban Board. (Scrumalliance.org, 2018).

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!”.

“There is no Kanban process for software development. At least I am not aware of one. I have never published one.”.

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.”

When we take Kanban, it’s modeled more after the manufacturing and assembly line. Scrum models have been created. The reason for using Scrum instead of developing the software for software development is the difference between the “Defined Process” and the “Empirical Process”. In short, the working process implemented in the input and output process for the process works better well known and repetitive (like a production line). There are fewer inputs and outputs available for the process, and Empirical Process works when it’s hard to repeat. All organizations have issues about getting Scrum. They are transferred from a product-based approach (manufacturing based approach) to an agile, empirical approach for specific approaches. It is considered to be an obstacle to optimizing the value between the current organizational culture and Scrum’s value driven approach. Then the organization urges it’s to change its current culture to gain this agility and value. When changing is very difficult, they often change scrum and hold barriers. Because we call this “ScrumButs”, “We use Scrum, BUT we have found that it is very difficult for us to have Scrums daily, so we should get them once a week.”. (The Scrum Crazy Blog, 2018).

We can say that Scrum is most useful when a new team starts to project on a project like Aegis. They tell them what to do, when to do and how to do. It says that what meetings actually need to be hold, and who should be attend and why should they talk about. These rules are useful for starting of the project. Kanban is useful after working well with a group and need to start researching ways for their improvement. They can try to change them and give them feedback to see the impact of their changes. Scrum’s biggest advantage is that it’s often out of the box in most cases. Things are bad, Scrum can often be better. And also, Kanban is limiting the working progress. So that, within a short period of time we cannot deliver the all features for the multiple stakeholders are really hard. According to the above clarifications, I can say Scrum is more suitable that the Kanban.

1.5. Scrum vs DSDM (Dynamic Systems Development Method)

The term AGILE may vary according to the methodology. But the principle and the practice are the same. In the Dynamic System Development System (DSLM), development is a ‘engineering activity’. And also, each recurring process is called the emerging solution. The output of Scrum is known as the “potential releasable increment”. DSDM has priority in delivering scalable agile projects and solution. DSDM for small direct solutions or large complex corporate projects is much the same. DSDM has been used efficiently for non- IT solutions not just for the development of software. DSDM often refers to “mature Agile”. DSDM only talks about policies and workflow of the system. (UKEssays, 2018).

The Dynamic System Development Methodology is the methodological analysis which used by the information system professionals to develop the projects of software which is invented from Rapid Application Development Methodology (RAD). Stapleton (1997) says that “DSDM describes project management, estimating, prototyping, time boxing, configuration management, testing, quality assurance, roles and responsibilities (of both users and IT staff), team structures, tool environments, risk management, building for maintainability, reuse and vendor/purchaser relationships – all in RAD environment.”. (UKEssays, 2018).

This is considered to be an agile project management methodology by which delivers the software systems on time and within the budget. This DSDM can also be included into. Personal Connection involved are Project Manager, Programmer, System Analyst and Facilitator. As detailed of the DSDM, I would say that Scrum is more suitable for Aegis system. (UKEssays, 2018).

2.      Stakeholders of the Aegis System and their roles within Scrum Agile Project Framework.

Table 1: Stakeholder Analysis for Aegis System

In scrum, there are three major roles. One is the product owner, second is the scrum master and the last is the scrum team or the development team. Product owner is the person who represents the stakeholders and is therefore a party outside the IT consulting firm. Therefore, the product owner can be anyone and is most likely selected by the government of Lazarus. Product owner sets the priorities on what needs to be developed and delivered first.

Scrum master is the person who coaches the scrum team and should not be seen as a team leader. Scrum master should be an expert in knowing how scrum works and how it should be applied as well. Since the scrum master take no responsibility of the work created by the scrum team and the scrum team is self-managed. The scrum master only shows the path the scrum team needs to take and make sure that everyone involved adhere to and respect the scrum methodology. Other than that, the scrum master is responsible for the smooth flow of work from the scrum team. That is to say, scrum master is responsible that the scrum team can work without any kind of a hindrance. These hindrances can be in the form of either factors beyond the control of the scrum team, say unnecessary demands from the stakeholders to include a feature as fast as possible, or problems with the company infrastructure, for an example, not enough space to hold the daily meetings, the network connection is too slow for the developers to work on etc… Lastly, these hindrances can be on a personal level, that is to say, the team member doesn’t have the necessary expertise to do a part of the coding, or that the developer’s computer has been broken, things like that. The scrum master is the one who creates the backlog and select the tasks for the current sprint. Therefore, the responsibility of the scrum master and the product owner cannot be done by a single person if that person is not someone special. Since the product owner should represent the stakeholders and should honor their ever-changing requirements, while the scrum master is there to protect his development teams from such ordeals.

Finally, the scrum team is the actual self-managed team that develops the product and is responsible for the quality of the product. The team should include people with different skill sets such as developers, architects and testers. This also means that each member should know at least a little about the work of the other members, since every developer might have to write tests in the end. This is why the team being collocated is important, this reduces the overhead associated with the team communications and the sharing of knowledge thus becomes easier. Typically, the recommended size of a scrum team is 7 +/- 2. This is done considering the management of the tasks and the communication overhead, the bigger the team becomes the harder it is to be self-managed. The team decides what to be done first, how to break down the requirement, and in what order the tasks are performed and by whom.

In conclusion, the scrum team, the scrum master and the product owner are all considered to be in the same level, no one is higher or lower than the other.

3.      Moscow technique for prioritization

3.1. Why Moscow technique is used for Aegis system

MOSCOW Prioritization plays a key role in AGILE Project Management. In the Agile project, it’s significant to understand the importance of different things. As time is a trusted resource, priority needs, functions, products, user opportunities etc. are priorities. Moscow is a way of determining the importance of the requirements for the project hence that the term we can say Moscow prioritization. So that the development team has decided to use Moscow prioritization for the Aegis project. Thus, Moscow prioritization which stands for MUST have, SHOULD have, COULD have, WON’T have. (Cupe.co.uk, 2018).

All the requirements are important, and at the very beginning of the AEGIS project, identify the potential needs of the team in delivering the largest and quickest business benefits of the project. Sometimes IT developers will first try to apply MUST Haves, SHOULD haves or COULD Haves. If the supply times are threatened, SHOULD haves or COULD Haves will be removed. The customer perspective of this prestige will be from the top to the middle, low and zero priority. (Cupe.co.uk, 2018).

3.1.1        Must or Must Have

This matter describes the satisfactory needs of the final solution. These requirements cannot be considered. Without these requirement, this project will not be successful. (Gantt Chart GanttPRO Blog, 2018).

3.1.2        Should or Should Have

A top priority characteristic is not essential for starting. But it is considered to be important and valuable to users of the Aegis project. Such a priority is assigned second place in the priority list. (Gantt Chart GanttPRO Blog, 2018).

3.1.3        Could or Could Have

Whether it’s needed or not, requirement that is desirable. According to this method, this point is first removed if the timescale of this project is at risk. (Gantt Chart GanttPRO Blog, 2018).

3.1.4        Won’t or Won’t Have

Not available in the current release, but can be included in a future development stage. Such requirements do not usually affect the project success.

Figure 2: Moscow Methods

3.2      Work Breakdown Structure for Aegis System

Figure 3: Work Breakdown Structure for Aegis System

3.3      Effectiveness of the Moscow method to Aegis project

The Moscow method is very effective because companies need an intergovernmental agreement on projects priorities for companies. Since the categories are not of MUST type and WON’T type, they should immediately be more defined for the project. Generally, COULD and SHOULD categories, which are the main points of reasoning, are quickly processed and resources and man power are used according to their priority level. (Powell-Morse, 2018).

The main advantage of the Moscow method is the allocation of some percentage for each category. Removing WON’T category provides more resources for IT consulting firm to plan for the COULD and SHOULD categories. Then we can allocate our resources from our percentages. Not only does it manage these resources properly, but also for specific productivity analysis. We will benefit from improved departments better than our ambitious efforts. All attempts can be shared between MUST, COULD and SHOULD categories. Once the MUST category has been completed, resources can be transferred. Many business analysts agree that the Moscow system is only meaningful in the timeframe, and many projects have this dock, which means they can usually be used. When priorities are set for a specific process, they are easily reviewed throughout the project period. We can report successes and can easily deal with failures under patronage of a quantitative priority structure. With our latest product features, we’ve installed it, the Moscow system will help the IT consulting firm to more efficiently upgrade our product portfolio and improve the product quality. (Powell-Morse, 2018).

Below is the calculation for average estimation.

Figure 4: Moscow Analysis

3.4      Use Case diagram for Organizing Management Services

Figure 5: Use Case diagram for Organizing Management Services

3.5      Use Case diagram for Situation Management

Figure 6: Use Case diagram for Situation Management

3.6      Use Case diagram for Mapping and Geo Location

Figure 7: Use Case diagram for Mapping and Geo Location

3.7      Use Case diagram for Resource management

Figure 8:Use Case diagram for Resource management

4.      User Stories for the MUST have requirements

1. Under Resource Management System

As a government agency administrator, I want to manage and allocate resources to NGO so that I can dispatch the resources to places that are requesting them.

Acceptance Criteria:

1. These resources need to be stored in resources hubs in NGO side.
2. NGO needs to be registered in the Government agency.
3. NGO worker will dispatch the resources to the places.

2. Under Mapping and Geo- location system

As a NGO administrator I want to ensure that the last known location that the workers have been updated so that I can identify and build teams to deal with requests for support.

Acceptance Criteria:

1. NGO worker should be a registered person who has the authority to access the system.
2. These requests must be approved ones by the government Agency administrators.
3. Each NGO worker must have mobile phones.

3. Under Situation Management System

As a government agency administrator, I want to approve when the emergency service is required so that I can request resources from NGO and asked them to allocate a worker to dispatch the resources.

Acceptance Criteria:

1. This emergency service will be coming under social media.
2. Only the government agency can approve the emergency services.
3. NGT administrator needs this approval for the resource allocation process.

4. Under organization management system

As a NGO administrator I want to submit information to the relevant teams so that I can allocate the most suitable person to resource distribution.

Acceptance Criteria:

1. Each worker should be registered in the Aegis system.
2. Each worker has their own profiles.

5.      Prototypes for two stories

User Story prototype for “As a government agency administrator, I want to manage and allocate resources to NGO so that I can dispatch the resources to places that are requesting them”.

1. ”:

Figure 9: Prototype for allocate resources

User Story prototype for “As a NGO administrator I want to submit information to the relevant teams so that I can allocate the most suitable person to resource distribution.

2. ”.

Figure 10: Prototype for update profiles

6.      Iterative Development for the prototype

6.1. Description of the iterative development

I have selected the prototype for “As a government agency administrator, I want to manage and allocate resources to NGO so that I can dispatch the resources to places that are requesting them”. Spiral processes (Iterative developments) respond to unique events and repeat them, again we will make mistakes, we will need responses, we will need several times before we do it correctly. In the demonstrated development process, we plan to design our project plan around the idea of iterations and fit the phases with them. we may consider five of the iterations: (Methodsandtools.com, 2018).

1. In the first iteration we suggested to do 90% analysis, 10% design.
2. In the second iteration we suggested to do 30% analysis, 50% design, 20% coding.
3. In the third iteration we suggested to do 10% analysis, 30% design, 70% coding.
4. In the fourth iteration we suggested to do 10% design, 50% coding, 40% testing and bug fixing.
5. In the fifth iteration we suggested to do 50% testing and bug fixing, 30% integration, 20% deployment.

The reality is that this process is not entirely bigger than any of us. At first, we will receive feedback. Gradually, the results obtained from every step gradually from every recurring period and we will need it to be gradually reduced. (Methodsandtools.com, 2018).

One complaint we can receive from an earlier process is that it takes a long time to see the result of the work. Of course, the software is not ready until the full end of this part of Aegis project. What can be done if the results are getting faster? Various Procurement Method can be used with the previous procedure. (Methodsandtools.com, 2018).

The basic idea is that Aegis users need to add the software more efficiently several times. All releases are full, useful and useable for Aegis system’s users. More functionality than any relevance is most useful for most important functionality. We will see how we can design our Aegis project. (Methodsandtools.com, 2018).

• First, let’s go through some of these analysis and design iterations. These stages are extremely complete. We can then select the content and schedule of the increments to grow. We will tell you that we have X, Y, and Z increments to provide Aegis users with this order.
• For increment X, we will be shown through all the phases until the software can be released. We hope to rebuild and create the analysis very little.
• For increment Y, we will update again through all the phases until the software can be released. We do not expect any analysis or designs.
• For increment Z, we will resubmit all the necessary steps until the software is released. We do not expect any analysis or designs.

This process can be portrayed as a picture in four of the above processes. The analysis and (architectural) design are reduced in each step. After the second, third and fourth steps, the process provides functionality.

By considering above sprint, we have to consider backlog grooming first before doing the Sprint planning. There is having three steps to doing the iterative development of this prototype. They are:

1. Backlog Grooming
2. Sprint Planning
3. Elaboration

6.2. Backlog Grooming

When we are considering backlog grooming for above user story, product owner or team representative is responsible for doing this. We are doing backlog grooming when we are in mid sprint. That’s mean mid of the user story.

Backlog grooming (referred to as maintenance or pre-planning) is not a regular event of the scrum process. But for these activities, Product owner, business analysist and group representatives are advised 10-15% commitment at every sprint. In pre-planning, everyone helps Sprint planning to be prepared for the meeting. This usually contains adding new epics and new stories, take out stories from existing epics and estimating effort (resource allocation process). Candidate user stories (based on priority) are identified the product owner for the next sprints, and the team representative performs a list of changes based on the technical feasibility. (LinkIn, 2018).

Groomed backlog will support streamline sprint planning; Otherwise, it can bounce on for hours. When the product backlog item contains clearly defined acceptance criteria and which are estimated by members of the appropriate team, the planning process should not be stressed or too long. By guaranteeing the time for maintenance, the team assures that this plan is preceded by prior to the sprint planning meetings. (LinkIn, 2018).

A backlog is a set of tasks to complete before code is released. During the product backlog grooming session, the development team works with the business owners for prioritizing a work list that is backlogged, and break the user stories for future use.

For an example: if the velocity is 33 Story Points (SP),

Expected Backlog groomed SP = 33 * 2

= 66

The backlog should have 66 SP of groomed stories (here the backlog   means the stories in backlog those were not committed ever, means [all SP] minus [SP from past and current Sprint]). (Agile Digest, 2018).

6.3. Agile Development Sprint Planning/ time-box Planning

First of all, we must decide on what is our sprint’s duration time. Short sprints allow us to regularly release the product working version that we produce. As a result, customers’ views will often be received and will reveal bugs and errors that might be available over time. Alternatively, we may take a long sprint duration. Developers will be allowed to work more thoroughly. Optimal sprint duration is defined as the average of these two options. As a rule, it takes about 2 weeks. The most important part of this phase is the cooperation between stakeholders and group members of the IT firm. The product owner determines the importance of the proper user story and scrum team defines the appropriate labor costs. Later, we can choose important user story from the product backlog. Then group members should decide how to solve them or solve this task. Next the sprint backlog should be created. It will consist of user stories that will be built on the current sprint. The amount of these stories depends on the time taken for each story points to be used in the stage of evaluation. The stories need to be finished by the team on time. (Gurendo, 2018).

At this meeting, the owner of the product and the team are discussing which stories fights for that sprint. A meeting between two to four hours is a conversation between the product owner and the team. At the Sprint planning meeting, the product owner describes the highest priority features of the product to the team. Asks questions sufficiently to turn users to make a high-level user story on the product backlog into the more detailed tasks of the sprint backlog. Product owner has to answer the questions, explaining or re-discussing acceptance criteria. The story of teams in story points are based on complexity and effort. The set of stories are broken down to tasks and tasks are jointly estimated in hours. The group should be estimated to vary from one member to another, depending on the experience of individuals. The Scrum method encourages collaboration and reduces the risk of over estimating or underestimating any task. (LinkIn, 2018).

There are two defined artifacts that result from a sprint planning meeting:

1. A sprint goals
2. A sprint backlogs

Sprint planning meeting is the highest plan to release the meeting will be of the highest productive value to the product owner and the highest business value, the development team has the power to push back and voice concerns or impediments. This is a good thing because the group can know about a legitimate barrier to moving ahead. This allows the team to work out their workload, work according to capacity and commit to a realistic goal. Creating unrealistic objectives and not acquiring it affects the stakeholders’ negative signal and the morale of the team. (LinkIn, 2018).

6.4. Elaboration

Each of these “levels” is regularly addressed at different points in each sprint. Usually a user story is started. If the development team needs some further clarification regarding on requirements throughout the day, the product owner must be available for consultation. To actually needs to develop the user story, we need to consider different levels such as Themes or Epics stories and features. Developing user stories dynamically means that large user stories fall into smaller ones and more detailed filling when they are implemented. The development team will answer questions whenever unanswered questions and whenever they work with a new user story, in order to continue with the development process. The product owner works with the development team to expand user stories, but the development team’s final decisions must be the final conclusion. (LinkIn, 2018).

6.5. Sprint Review Meeting

Sprint review finally check the inverters and adapt product backlog if necessary. In the sprint review, Scrum team and stakeholders collaborate on Sprint. Sprints are based on product backlog and can be attended by participants who can make the value better. This is an informal meeting, not like a status meeting, but rather the elicit of feedback and the development of collaboration to present the increments. This is a four-hour meeting for Sprint. This event is usually shorter for short-season sprints. This event occurs and the participants are aware of its purpose. Scrum Master teaches everyone participating within the timebox. The Sprint Review results in the revised product backlog that defines the product backlog which is probable for the next sprint. In order to meet new opportunities, the product backlog can be adjusted to suit the needs of the time. (Scrumalliance.org, 2018).

6.6. Sprint Retrospective

Sprint Retrospective is to create a plan to improve the Scrum team on the next sprint. After Sprint Retrospective Sprint Review prior to the next Spring Sprint. This is a three-hour meeting for Sprint in one month. This event is usually shorter for short-season sprints. This incident occurs, and the Scrum Master certifies that the worker’s work has been understood. Scrum master certifies that this meeting is a positive and effective one. The scrum master teaches all to keep it in the timebox. As per the team member in the particular meeting, the scrum master participates from the accountability over the Scrum process. To improve for the Scrum teams, the Scrum Master encourages within the design process and function within the framework and its development process to be more efficient and fun at the next Sprint. In each Sprint Retrospective, if the Scrum team improves the work process or if it coincides with the production process or organizational standards, the “done” definition is designed to increase product quality.

6.7. Change Management

Changes in Scrum (as well as the new functionalities) at the Sprint Planning meeting are given priority by the Product Owner. Every day, a member of one team has a Daily Scrum Meeting who must need to answer the following three questions such as What have you done since the last Daily Scrum? What will you do between now and the next Daily Scrum? What got in the way of doing your work?

Issues that could affect issues are raised, and the Sprint Backlog or Product Backlog has added more capacity depending on the size. Close collaboration and processes and tools should be kept simple and simple by communicating management changes with an informal face to face communication, successfully meeting the need of a diligent project. (Scrum Projects, 2018).

In order to respond to changes, the Scrum method is implemented in several ways. Waiting time is abolished for a formal change proposal to authorize and authorize the Scrum Team to correct problems with the behavior and structure of the code. By holding a weekly Scrum Meeting, developers will be able to stop major problems and make sure everyone in the group is informed. Reduce time between short sprint requests and implementation. Teams and product owner will be found in Sprint planning. Face-to-face communication can be quickly communicated, and the face-to- face communication with minimum waiting and documentations and will alert the product owner to the impact and risk of the team, and he or she will be tempted to control the scope and priorities. (Scrum Projects, 2018).

Incremental and iterative development can be used to obtain customer feedback about the most potent methods for change management, sometimes very small but very frequently executable milestone and enforceable. In addition, there is close customer relationship to popularize face-to-face relationships and face-to-face communication between customers and the development team. Incremental and iterative development can be used to obtain customer feedback about the most potent methods for change management, sometimes very small but very frequently executable milestone and enforceable. In addition, there is close customer relationship to popularize face-to-face relationships and face-to-face communication between customers and the development team.

6.7. Final prototype after changes

Figure 11: Final prototype after changes

7.      A first cut class diagram showing only the class names and attributes and relationships that will form the basis of the database for the information system that will be developed.

Figure 12: Class Diagram for Aegis system

8.      Conclusion

In today’s competitive global event, software products are short on time in the market. The product life cycle or the development of a system development begins with market research on the need of a customer or concept. System Inputs and Operations End. Due to changing global competitiveness and customer requirements according to the needs of the customers, a process is needed to change the needs of the customer initially altered at the development stage and need to be developed rapidly. The evidence points to an increase in popularity and will continue in the coming years. There are many disadvantages when using the traditional methodology for projects, but the advantages of using scrum for system development cannot be explained frequently.

References

1. A SYSTEMATIC LITERATURE REVIEW ON AGILE PROJECT. (2018). [ebook] Available at: https://pdfs.semanticscholar.org/0a52/a9e8b5bfd5592cb684ece12eaaa98e20bc23.pdf [Accessed 13 Jan. 2018].

2. Ambysoft.com. (2018). Examining the Agile Manifesto. [online] Available at: http://www.ambysoft.com/essays/agileManifesto.html [Accessed 13 Jan. 2018].

3. Smartsheet. (2018). Comprehensive Guide to the Agile Manifesto. [online] Available at: https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto [Accessed 14 Jan. 2018].

4. The DSDM Agile Project Framework v1.11. (2018). [ebook] Available at: https://www.agilebusiness.org/sites/default/files/the_dsdm_agile_project_framework_v1_11.pdf?token=yqzXtW1a1 [Accessed 14 Jan. 2018].

5. Managing Task Uncertainty with the Agile Project Methodology. (2018). [ebook] Available at: https://pdfs.semanticscholar.org/11a1/bfc27ae37f392cfaf1eac517054511282434.pdf [Accessed 14 Jan. 2018].

6. The DSDM Agile Project Framework v1.11. (2018). [ebook] Available at: https://www.agilebusiness.org/sites/default/files/the_dsdm_agile_project_framework_v1_11.pdf?token=yqzXtW1a1 [Accessed 14 Jan. 2018].

7. Nicholson, S. (2018). Agile Scrum Roles And Responsibilities. [online] KnowledgeHut Blog. Available at: https://www.knowledgehut.com/blog/agile-management/agile-scrum-roles-responsibilities [Accessed 14 Jan. 2018].

8. Scrumstudy.com. (2018). SCRUMstudy Blog. [online] Available at: https://www.scrumstudy.com/blog/roles-and-responsibilities-in-scrum/ [Accessed 14 Jan. 2018].

9. Cupe.co.uk. (2018). MoSCoW Prioritisation. [online] Available at: https://www.cupe.co.uk/moscow-prioritisation.html [Accessed 15 Jan. 2018].

10. Gantt Chart GanttPRO Blog. (2018). MoSCow Method. [online] Available at: https://blog.ganttpro.com/en/prioritization-techniques-and-methods-for-projects-with-advantages-of-moscow-model/ [Accessed 15 Jan. 2018].

11. Powell-Morse, A. (2018). Effectiveness of Moscow Method. [online] Airbrake Blog. Available at: https://airbrake.io/blog/software-development/moscow-method-delivery-standards [Accessed 15 Jan. 2018].

12. Adapting and Using Scrum in a Software Research and Development. (2018). [ebook] Available at: http://www.fsma.edu.br/si/edicao9/FSMA_SI_2012_1_Principal_2_en.pdf [Accessed 16 Jan. 2018].

13. Anon, (2018). accessed Jan 16 2018. [online] Available at: https://www.researchgate.net/publication/263808188_A_Scrum_Framework_for_Requirement_Engineering_Practices [Accessed 16 Jan. 2018].

14. VersionOne. (2018). Agile Methodologies for Software Development. [online] Available at: https://www.versionone.com/agile-101/agile-methodologies/ [Accessed 16 Jan. 2018].

15. Cohn, M. (2018). Scrum Methodology and Project Management. [online] Mountain Goat Software. Available at: http://www.mountaingoatsoftware.com/agile/scrum [Accessed 16 Jan. 2018].

16. Methodsandtools.com. (2018). Another look at incremental and iterative development. [online] Available at: http://www.methodsandtools.com/archive/archive.php?id=14 [Accessed 20 Jan. 2018].

17. Cohn, M. (2018). Scrum of Scrum. [online] Mountain Goat Software. Available at: https://www.mountaingoatsoftware.com/articles/advice-on-conducting-the-scrum-of-scrums-meeting [Accessed 20 Jan. 2018].

18. Scrumalliance.org. (2018). Scrum Versus Kanban. [online] Available at: https://www.scrumalliance.org/community/articles/2014/july/scrum-vs-kanban [Accessed 20 Jan. 2018].

19. The Scrum Crazy Blog. (2018). Kanban vs. Scrum. [online] Available at: https://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/ [Accessed 20 Jan. 2018].

20. UKEssays. (2018). DSDM. [online] Available at: https://www.ukessays.com/essays/information-systems/dynamic-systems-development-methodology.php [Accessed 20 Jan. 2018].

21. LinkIn. (2018). Backlog Grooming. [online] Available at: https://www.linkedin.com/pulse/difference-between-product-backlog-grooming-sprint-planning-taylor/ [Accessed 21 Jan. 2018].

22. Agile Digest. (2018). Agile Digest. [online] Available at: http://agiledigest.com/agile-digest-tutorial/product-backlog-grooming/ [Accessed 21 Jan. 2018].

23. Gurendo, D. (2018). Scrum Methodology Phases. [online] XB Software. Available at: https://xbsoftware.com/blog/software-development-life-cycle-sdlc-scrum-step-step/ [Accessed 21 Jan. 2018].

24. Scrumalliance.org. (2018). The Scrum Guide – Scrum Alliance. [online] Available at: https://www.scrumalliance.org/why-scrum/scrum-guide [Accessed 21 Jan. 2018].

25. Scrum Projects. (2018). [ebook] Andreas Bergström. Available at: http://fileadmin.cs.lth.se/cs/Personal/Lars_Bendix/Teaching/Lund/Theses/Bergstrom08/Bergstrom08.pdf [Accessed 22 Jan. 2018].