CEN 4021 Software Engineering II

CEN 4021 13th Lecture

CEN 4021 CEN 4021 Software Engineering II Software Engineering II

Instructor: Masoud Sadjadi

http://www.cs.fiu.edu/~sadjadi/

[email protected]

Software Project Planning (POMA)A Review

13th LectureCEN 4021: Software Engineering II

AcknowledgementsAcknowledgements

Dr. Onyeka Ezenwoye

Dr. Peter Clarke

2


AgendaAgenda

Organizing (POMA)– A review


OrganizationOrganization

Seeks to construct a software development, support, and service organization based on the project plan.

Activities include:– Acquiring various skilled individuals needed for the project.

– Obtaining the tools to support the process and methodologies.

– Creating a set of well-defined metrics to track and gauge the project.


Human ResourcesHuman Resources

Possible software organizational structures– Software development organization– Software support organization

Preparations to acquire human resources– Recruiting, hiring

Projects require– large number of people with range of skills.– Multiple teams with specialized skills (e.g., testing,

installation). Personnel hiring may be done in parallel with

preparing organizational structure. Organizing groups require understanding of project

plan.


Project Management

Database Management Application Design Build/Packaging

Tools SupportApplication ManagementUser Interface Design

Process and MeasurementApplications TestingRequirements Analysis

System Design Systems Testing

Publication and Information Design

Publication and InformationDevelopment

Fig. 6.1 General Software Project Organization


Software Development Software Development StructuresStructures

• Refining the General Organizational structure

1. Matrix vs. Hierarchical Orientation

2. Functional Orientation

3. Highly Specialized Organization


Matrix vs. Hierarchical Matrix vs. Hierarchical OrientationOrientation

The software development structure is flexible based on the size of the project.

The organization structure may be represented either as a hierarchy or as a matrix.– Hierarchy org.: all the people associated with a project are

grouped into functional departments that report directly within the vertical line of command of the organization

– Matrix org.: people are grouped based on the functions they perform.

Functions may be performed by non-members of official project organization

Less function duplication, better focus on specialized skill.What about team loyalty and confusion?


Functional OrientationFunctional Orientation

The general orgl. structure may be further refined to show a more precise structure.

It is important that the org. be defined down to a level where each individual can see her/his name.

Project Manager (Sally Thomas)

Project Interface to process & tools (to be

hired)

Project interface to prog center. (Mark Burke)

Apps. Designer (John Chang)

Apps. Designer (Kim O’Conor)

UI Designer (to be hired)

Req. Analyst (Tom Shaker)


Highly Specialized OrganizationHighly Specialized Organization

Software Development Manager (Sally Thomas)

Apps. Engineer (to be hired)


Apps Engineer (to be hired)

Apps. Analyst (Tom Shaker)

Senior Apps. software Engineer

(Tom Shaker)

Apps. Engineer (Laura Lang)


Apps Engineer (to be hired)

Senior Apps. software Engineer

(to be hired)

Software development specialization


Highly Specialized Highly Specialized OrganizationOrganization

More specialized, that is the groups responsible for only the development of software, but not the information development and publication task.

Group does not perform any of the requirements gathering and specification activities, nor does it handle any independent testing.


Software Support StructuresSoftware Support Structures

Spmr must set up an extensive customer interface group, such as call service dept. that handles the following duties:– Answer calls– Analyze each problem– Respond to the customer if a possible solution exist– Generate a problem report when an immediate solution does not

exist– Track problem resolution activities– Report and deliver solutions to the customer– Close problems


Software Support Software Support OrganizationOrganization

Software Support Manager

Problem resolution Analyst

Customer level 2 support leader


Customer Call support analyst






Software support Engineer




Recruiting and Hiring Software Recruiting and Hiring Software PersonnelPersonnel

Once the organizational positions are outlined, the software project management needs to fill open positions.

The actual hiring of the employees starts with having a clear definition of the open position in terms of the skills, training, and character of the candidates required for each position.

Recruiting: It is usually not sufficient to provide a general description

of the position title to the HR department.


AgendaAgenda

Organizing (POMA)– Organizing

Human resources– The Project Team


Project Team Life CycleProject Team Life Cycle

Very few projects can be completed by individuals. Group becomes a team through proactive efforts by

members and project manager. Typical project team life cycle goes through three

stages:– Team formation– Team development– Team maintenance



Teams need forming, developing and maintaining Amount of management activity differs at different

stages of the team life cycle.

Relative management

Effort

Team Stages

Forming

Developing

Maintaining



Team building activities center on education and training on areas like:– Building trust– Negotiation skills– Listening skill– Responding to pressure

Project manager must ensure that there is enough time in the project schedule for such training.


Team FormationTeam Formation

Having the best people does not guarantee success unless experts work effectively as a team.

Project might be delayed or fail due to personnel conflicts. Tasks may be independent but interrelated.


Team FormationTeam Formation

Project manager will review tasks and decide on the skills required to complete them.

Team members should possess other behavioral characteristics or “soft skills”.

No perfect person exists, managers should not look for mythical candidates.


Technical Software skillsTechnical Software skills

Technical skill– A specialized skill in a subject that is needed to perform the

activities in that subject domain. Usually requires knowledge and training in a scientific, engineering, or business discipline.

– The skill areas include: Requirements solicitation and specification Database design Design, programming and debugging Test design and test script writing


Soft skills and personal traitsSoft skills and personal traits

Traditionally, managers tend to focus on technical skills and experience.

Managers should look for other characteristics, many of which are “soft skills”

Soft skills– A non-technical skill that can be utilized on multiple

occasions and is not restricted to any specific domain.


Soft skills and personal traitsSoft skills and personal traits

These personal traits might include:– Personal ambition– Interpersonal communication skill– Sense of urgency– Strongly held likes and dislikes– Attention to detail

Some team member may have negative personal traits.– E.g., Personal ambition over team goals.


Team DevelopmentTeam Development

Project manager may need to intervene in the team’s adjustment process.– Changing team members– Dismissing participants



Some key activities for project managers– Ensuring communication is taking place– Ensuring member are treated with respect– Ensuring clear understanding of roles and assignments– Ensuring the team is not harboring a chronic laggard– Ensuring members understand team goals– Ensuring that members follow the agreed-upon process



To promote team building, managers may sponsor:– Off-site meetings– Motivational speakers– Team games, e.g., softball– Team presentations– Remembering birthdays

Group events create strong bond through trust– Member can relate experience to need for interdependence

in software project.



Team members behavior need to be continuously monitored

Project managers should perform conscientious socializing– Informal data gathering to pick up any signs of team disorder

(e.g., non-return of emails).

With remote and virtual teams– Communication is a major source of team related problems.

Members may need counseling on basic working etiquette



Team or personal Issues One or more people are upset about something and

its negatively impacting the team.– E.g., personal (“I can’t stand working with Fred”)– E.g., systemic (“I hate how we do code reviews”)

Start by talking one-to-one to people involved Ask what is going on and what can be done? Seek out causes not just symptoms.


Team Development Team Development

The disagreement is preventing progress.– Seek mutually beneficial outcomes (do not compete)– Find a point of unification (e.g., project need to be on time)– Don’t let personality traits distract you from the goal.– Force people to talk about interests (not positions) and reach

agreement– Be strong but supple

Know points of flexibility If you can give more time, can you allocate more money?


Team MaintenanceTeam Maintenance

Rewarding team members Punishing team members Handling team attrition Team member growth


AgendaAgenda

Organizing (POMA)– Processes, Methodologies and Tools

Organization of Process


ProcessesProcesses

In addition to hiring new employees, other new resources necessary for the software project must be considered, acquired, established, and installed during the organizing phase.

The process used to develop the software must be clearly defined.


ProcessesProcesses

The process must be tailored depending on some of the following:– The size and complexity of the project based on the

deliverables

– The maturity of the organization

– The history of the working relationships of the people

– The size of the organization

– The goals of the software project


Process MapProcess Map

There is a need to map the overall process to clearly list the activities carried out with in each step, and to explain any relationships among the steps.

Diagram:– For waterfall-like process

– Arrows show the flow of activities.

– Dotted arrows indicate the potential for backward flow.



The conditions for the successful completion or the exit criteria of a step, which allow the work flow to continue to the next step, need to be provided as a companion to the process map.

Typical exit criteria from the design process:– All the functional and nonfunctional reqs. are designed including

the following:The systems and communication interfacesDatabase and file structureSpecial constraints: performance, security, backup/recovery, etc.



Typical exit criteria from the design process cont:– All of the design is documented and represented in the

preciously specified format and language.

– The design document is stored in a configuration management tool.

– The design document is reviewed and all errors found have been fixed and captured in the updated design document.

The defined exit criteria for the process steps provide a management and a team approach to controlling the flow of activities.


ProcessesProcesses

Configuration Management Defn: A set of procedures that define, track, and control

artifacts produced during the development, support, and maintenance of software.


ProcessesProcesses

Configuration Management Configuration management is made up of a complex set

of activities including the following key activities: Part 1: Definition and Setup

- Defining and listing the artifacts that need to be managed

- Defining the granularity of managing the artifacts and designing the directory scheme to accommodate that level if granularity

- Defining the rules for accessing the artifacts


ProcessesProcesses

Configuration Management cont• Part 2: Control and track

- Defining the security and controls needed to manage the artifacts

- Storing retrieving, locking, and unlocking artifacts based on the predefined rules

- Maintaining all of the tools employed to help in configuration management.

Note configuration management spans the entire project.


ProcessesProcesses

Process Introduction and Education Members of a project team may come from a variety of

backgrounds, all of which use some form of a process. Even if this process is some form of chaotic organization i.e., the process is formulated as the project progresses.

Education and communication of project progress should come in stages.

There are many approaches, one such approach is as follows:


ProcessesProcesses

Process Introduction and Education Stage 1: Process Introduction

– Provide the intro and education, if necessary, to the general process chosen for the project.

– Provide the rationale behind the specific process.

– Point out both the positive and the negative as well as any portion of the process that is still untested.

– Point out any past history, if available.


ProcessesProcesses

Process Introduction and Education Stage 2: Feedback and Modification cont

– Allow team members to debate and study the process on their own.

– Ask for written feedback.

– Collect and analyze the responses

– Make appropriate modifications and prepare for responses to these changes.

– Bring the team together, providing the team members with feedback on which suggested modifications were accepted and explaining what was done with both the accepted and the rejected suggestions.


ProcessesProcesses

Process Introduction and Education Stage 3: Acceptance

– Ask whether any further education is needed and provide it as appropriate.

– Ask for concurrence and acceptance of the process.

Stage 4: Reinforcement– Quickly review the process and ask for any further input to its

implementation.

– Make any adjustments and update the process as needed.


ProcessesProcesses

Process Introduction and Education The effort required to organize, communicate, educate,

and gain acceptance of the process may be longer than many people would like.

Stage 4 (reinforcement) may be performed repeatedly as needed, but not excessively.

As new employees come on board, they must also be introduced to the project process.

Spmr needs to ensure that the team is clear about, and ready to follow the process map.


MethodologiesMethodologies

Methodology is a prescribed set of steps to accomplish a task.

The process provides the macro steps the methodology provide the micro steps, i.e., the difference between a methodology and a process is a matter of degree.

Spmrs have traditionally been highly involved in discussion on methodologies for the following reasons:

1. Need to keep up with the new methodologies

2. Promotion was linked to performance using a methodology


MethodologiesMethodologies

Spmrs must be familiar with the most appropriate methodology.

Spmrs need to monitor how the methodology is used on the project.

The spmr needs to ensure that the team is prepared to use the methodology. Usually describe at two levels:

1. Higher-level is a more process oriented way i.e., major substeps to be employed are listed and their relationships shown.

2. Deeper level describes the specific methods in each substep.


ToolsTools

Tools should reduce work and increase productivity and efficiency.

Tools represent a significant set of resources for software projects.

There have been claims of 50% - 200% gains in productivity as evidence of a particular tools’ effectiveness. On the other hand the expected savings for some tools did not materialize.

Spmrs should take a realistic note of what should be expected and what effort will be required to achieve the expectation.


Tool Identification and Preparation Some activities the manager should carry out to prepare

for the acquisition and use of the tool:– Identify the specific steps and activities that the tool is expected

to automate or improve.

– Explore realistic expectations for the tool, stated in terms of productivity gain or efficiency gain that the automation of these steps will bring.

– Review the various tools available that will meet these expectations.

– Review the training needed to attain the level of competency for the expected gains.

ToolsTools


Tool Identification and Preparation:– Choose the specific tool to be acquired, working out the needed

terms and conditions.

– Announce the decision.

– Set and communicate the realistic expectations in terms of productivity gains that the team should be experiencing.

– Schedule and facilitate the necessary training.

– Acquire and set up the chosen tool.

– Ensure the proper continuous support of the tool is in place.

– Communicate the project policy for usage of this tool

– Set up the mechanism to enforce the usage policy.

ToolsTools


AgendaAgenda

Organizing (POMA)– Goals and Measurement


Goals and MeasurementGoals and Measurement

During the planning phase the goals for and measurements of, the key attributes of the product and services are determined.

Many of the goals for the system are deduced from the functional and nonfunctional requirements i.e. obtained from the customer.

Measurable attribute: An attribute for which there is a well-defined metric and a methodology for its measurements.


Validation of goal:– Comparing a stated goal for an attribute with the actual

measurement taken for the attribute.

Verification of measurement: – Ensuring that the measurement of an attribute is properly taken

and recorded.

Metric: – The unit used to characterize an attribute.

Measurement: The act of characterizing an attribute, which may involve multiple steps, utilizing the agreed upon metric for that attribute.



Deliverable-related metrics Deliverable-related metrics and measurementsand measurements

Some software deliverable attributes include:– Quality

– Usability

– Functional completeness

– Maintainability

– Modifiability

– Reliability

– Installability

Requires some thought and insight before a reasonable goal and metric can be designed


Project and project-related Project and project-related metrics and measurementsmetrics and measurements

manager is usually required to describe the project in terms of the following:

– Schedule integrity

– Cost minimization

– Productivity

– Efficiency

– Cost-effectiveness

– Employee morale


The project plan identifies important attributes and their goals. The metrics and measurement scheme for these goals were also conceived.

In the organizing phase several other important notions must also be considered by managers. – Are the goals and their associated measurement schemes

clearly defined?

– Has the organization embraced the measuring scheme?

– Has the cost of measuring been taken into account?



It is important that the project team understand the definitions of goals and measurements of the project.

To alleviate the problem of the team not understanding the goals and measurement scheme, the spmrs should:– Review the goals set for the product and project attributes

– Review the measurement scheme and modify if necessary

– Build an “operational” plan for the measurement schemes



The desired goals of a project should be stated in a quantitative way.

The classic example of a goal is “easy to use”. What does “easy to use” mean??? For goals that can be ambiguous or vague. Decompose them into subgoals. If the initial requirement was “The product should be easy

to use” one decomposed subgoal can be:– Every function in the product should be completed by the user

without external intervention.



After identifying subgoals, ask the following questions:– Is the subgoal more specific than the original goal?

– How would we gauge the transformed attribute?

– Is there a need for a specific activity that will allow us to gauge its attainment?

The precise metric and measurement methodology should be defined in terms of a particular test if possible.



For “ease of use” example usability test steps might be:

1. A test case is designed for each function in the product.

2. A numerical count is kept of the number of test cases that are successfully executed by a test subject without any external intervention.

3. This test is repeated with the predetermined number of test subjects to ensure the results’ statistical relevancy.

4. All the unsuccessful test cases are summed.



A reasonable goal for such a test is to have 5% unsuccessful or 95% successful test cases.

Some measurements can be potentially misleading.– See text book for discussion on the meaning: totally complete,

mostly complete, partially complete, and not complete.

If you are using categories to measure if goals are achieved make sure that:– Create categories that exhaustively cover the range of metrics

– Each category is mutually exclusive of any other category



Building a measurement operational plan: Each item to be measured in the plan may require a

slightly different operational plan. When refining the operational plan the following

refinements steps should be considered:– Steps to ensure that the process and methodology are modified

to include the details needed to implement each plan.

– Steps to ensure that proper resources are made available in a timely manner.



– Steps to ensure that necessary metrics and measurement schemes are defined for each plan item

– Steps to ensure that goals are defined for the implementation and that the achievement of the goals is validated.

Operational Plan: A plan that contains all the details of how to implement what is contained in a general project plan.



Operational plan allows for successful measurement during the monitoring phase of the project.

During the organization of the project some elements of the plan may have to be revisited therefore a further refinement of the plan is essential.



The following items should be considered during the organizing and preparation phase of the POMA life cycle:

– Any additional goal clarification and decomposition

– Well-defined goal validation

– Specific measurement techniques and schemes

– Any process extensions and modifications needed to accommodate measurements

– Additional software/hardware tools needed for measurement activities



Embracing the measurement scheme: It is very important to get the team on board with the

organizational plan for the measurements of the goals. Some measurement schemes may take on quite a bit of

complexity.



Manager should not perform all the analysis and justification studies by themselves. Other team members should participate for the following reasons:– More team members would understand the goals and

measurements.– More non-management team members would feel committed to

the goals and measurements.– Some team members may be counted on to “spread the

message” and educate other team members.– Sharing the burden would lessen the workload of the manager.– Distributing the knowledge would lessen the general fear of being

measured.– Team ownership of the goals would be more likely to be

achieved.



Goal Attainability Measurement of the process will make some employer

feel that they are being continually watched. Sometime the measurements are used to improve the

process for future projects. A spmr should be realistic about the expectation of

including the measurements of goals in the process. Before collecting any data explain how the data will be

used to the team members. The goals and measurements activity should be properly

planned, and the team should be included in the development of some of the goals.



Goal Attainability The team must embrace the goals and measurements as

their own. During the organization and preparation phase the spmr

must actively and positively communicate the goals, measurements and measurement scheme to the team.

All team members must be included in the communication about the goals and measurements.



Goal Attainability To win acceptance and positive reception of the goals

and measurements spmr must ensure the following:– A well-defined goal and measurement scheme

– Attainable goals

– The team’s participation in the setting of the goals

– The team’s understanding and belief in the goals and measurements

– The commitment of qualified resources for measurement



Measurement cost: Goals and measurements are important yet few software

projects do it. Why?– “Success” is often gauged by only a single goal e.g., a

deliverable’s due date.

– The organization may not see the value of setting goals and measurements or may fear the process.

– Management may not supply enough resources for the goals and measurements activities.

– Team may oppose the goals and therefore do not measure them.


CEN 4021 Software Engineering II

Documents

Transcript of CEN 4021 Software Engineering II