Assignment Tasks

Task 1 – 20 Marks
Table 1. List of Stakeholders

Stakeholder group Organisations, groups and/or individuals

Cancer networks Public hospital CEOs and Directors of cancer services

Private Hospital CEOs and Directors of cancer services

Private healthcare organisations

Multidisciplinary teams (members and coordinators;

state-wide or service level)

Identified cancer care champions/leaders

Service data managers

Health professionals and Cancer clinicians and health professionals

professional groups State/territory branches or faculties of health professional

associations and societies, e.g.

- AMA

- Cancer Nurses Society

- Australian Association of Practice Managers

- RACGP

State/territory Cooperative Oncology Groups

State/territory Clinical Trials Groups

General practitioners and Primary Health Networks

primary care General practitioners

Community primary care services

Aboriginal medical services

Non-government State/territory Cancer Council

organisations State/ territory Indigenous health organisations

State/territory branch of cancer organisations, e.g.

Leukaemia Foundation
Stakeholder group Organisations, groups and/or individuals

Consumer organisations State/territory cancer consumer/advocacy groups

State/territory cancer support group networks

Patients/carers Cancer patients, their careers and family members

Task 2 – 20 Marks

Interview
Interviews of stakeholders and users are critical to creating the great software.
Without understanding the goals and expectations of the users and stakeholders,
we are very unlikely to satisfy them. We also have to recognize the perspective of
each interviewee, so that, we can properly weigh and address their inputs. Listening
is the skill that helps a great analyst to get more value from an interview than an
average analyst.

Observation
By observing users, an analyst can identify a process flow, steps, pain points and
opportunities for improvement. Observations can be passive or active (asking
questions while observing). Passive observation is better for getting feedback on a
prototype (to refine requirements), where active observation is more effective at
getting an understanding of an existing business process. Either approach can be
used.

Prototyping
Prototyping is a relatively modern technique for gathering requirements. In this
approach, you gather preliminary requirements that you use to build an initial
version of the solution - a prototype. We will show this to the client, who then gives
you additional requirements. You change the application and cycle around with the
client again. This repetitive process continues until the product meets the critical
mass of business needs or for an agreed number of iterations.
Why requirements are not always clear
I'm often faced with incomplete or confusing requirements. The client does not
specify a clear requirement, but simply says "I need a product that can do such and
such work." Hence, creating test requirements becomes a difficult task. Please give
me some insight on how to handle projects when the requirements are not clear.
Unfortunately, we can't expect customers always to provide nicely structured,
clearly written, unambiguous.

Task 3 – 20 Marks

Project Management

Initiating- In this stage, goals, objectives and scope of the project will be
defined. I aim to build a health improvement project which will reduce the rate
of canner in local area by educating them.

Planning - In this stage, all the tasks to be done will be defined assigned to
each tasks to respective developer.

Execution - In this stage, project team is built and resources are collected &
allocated.

Monitoring - In this stage, project tasks are monitored and project plan are
updated to reflect the actual performance.

Closing - In this stage, after delivering the project output, project is finally
closed down.
Task 4 – 20 Marks

Agile Vs Traditional SDLC Models

Agile is based on the adaptive software development methods, whereas the

traditional SDLC models like the waterfall model is based on a predictive approach.
Predictive teams in the traditional SDLC models usually work with detailed planning
and have a complete forecast of the exact tasks and features to be delivered in the
next few months or during the product life cycle.

Predictive methods entirely depend on the requirement analysis and planning done
in the beginning of cycle. Any changes to be incorporated go through a strict
change control management and prioritization.

Agile uses an adaptive approach where there is no detailed planning and there is
clarity on future tasks only in respect of what features need to be developed. There
is feature driven development and the team adapts to the changing product
requirements dynamically. The product is tested very frequently, through the
release iterations, minimizing the risk of any major failures in future.

Customer Interaction is the backbone of this Agile methodology, and open

communication with minimum documentation are the typical features of Agile
development environment. The agile teams work in close collaboration with each
other and are most often located in the same geographical location.

Agile Model - Pros and Cons

Agile methods are being widely accepted in the software world recently. However,
this method may not always be suitable for all products. Here are some pros and
cons of the Agile model.

The advantages of the Agile Model are as follows −

 Is a very realistic approach to software development.

 Promotes teamwork and cross training.

 Functionality can be developed rapidly and demonstrated.

  Resource requirements are minimum.

 Suitable for fixed or changing requirements

 Delivers early partial working solutions.

 Good model for environments that change steadily.

 Minimal rules, documentation easily employed.

 Enables concurrent development and delivery within an overall planned

context.

 Little or no planning required.

 Easy to manage.

 Gives flexibility to developers.

The disadvantages of the Agile Model are as follows −

 Not suitable for handling complex dependencies.

 More risk of sustainability, maintainability and extensibility.

 An overall plan, an agile leader and agile PM practice is a must without

which it will not work.

 Strict delivery management dictates the scope, functionality to be delivered,

and adjustments to meet the deadlines.

 Depends heavily on customer interaction, so if customer is not clear, team

can be driven in the wrong direction.

 There is a very high individual dependency, since there is minimum

documentation generated.

 Transfer of technology to new team members may be quite challenging due

to lack of documentation.

Conclusion

The agile method is better than traditional SDLC in terms of functionality,

effectiveness and quality and I also recommend the agile over traditional SDLC.
Task 5 – 20 Marks

Project Evaluation
 A high level assessment of the project
 to see whether it is worthwhile to proceed with the project
 to see whether the project will fit in the strategic planning of the whole
organization
 Want to decide whether a project can proceed before it is too late
 Want to decide which of the several alternative projects has a better
success rate, a higher turnover, a higher ...
 Is it desirable to carry out the development and operation of the software
system?

Approaches of Project Evaluation

 Strategic assessment
 Technical assessment
 Economic assessment

Evaluation Methods
 Cost-benefit analysis
 Cash flow forecasting
 Cost-benefit evaluation techniques
 Risk analysis

Project Planning
Software project planning is task, which is performed before the production of
software actually starts. It is there for the software production but involves no
concrete activity that has any direction connection with software production; rather
it is a set of multiple processes, which facilitates software production. Project
planning may include the following:

Scope Management
It defines the scope of project; this includes all the activities, process need to be
done in order to make a deliverable software product. Scope management is
essential because it creates boundaries of the project by clearly defining what
would be done in the project and what would not be done. This makes project to
contain limited and quantifiable tasks, which can easily be documented and in turn
avoids cost and time overrun.

During Project Scope management, it is necessary to -

 Define the scope

 Decide its verification and control
 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope

Project Estimation
For an effective management accurate estimation of various measures is a must.
With correct estimation managers can manage and control the project more
efficiently and effectively.

Project estimation may involve the following:

 Software size estimation

Software size may be estimated either in terms of KLOC (Kilo Line of Code)
or by calculating number of function points in the software. Lines of code
depend upon coding practices and Function points vary according to the
user or software requirement.

 Effort estimation
The managers estimate efforts in terms of personnel requirement and
man-hour required to produce the software. For effort estimation software
size should be known. This can either be derived by managers’ experience;
organization’s historical data or software size can be converted into efforts
by using some standard formulae.

 Time estimation
Once size and efforts are estimated, the time required to produce the
software can be estimated. Efforts required is segregated into sub
 categories as per the requirement specifications and interdependency of
various components of software. Software tasks are divided into smaller
tasks, activities or events by Work Breakthrough Structure (WBS). The
tasks are scheduled on day-to-day basis or in calendar months.

The sum of time required to complete all tasks in hours or days is the total
time invested to complete the project.

 Cost estimation
This might be considered as the most difficult of all because it depends on
more elements than any of the previous ones. For estimating project cost, it
is required to consider -

 Size of software
 Software quality
 Hardware
 Additional software or tools, licenses etc.
 Skilled personnel with task-specific skills
 Travel involved
 Communication
 Training and support