CEN 4021 Software Engineering II

CEN 4021 3rd Lecture

CEN 4021 CEN 4021 Software Engineering II Software Engineering II

Instructor: Masoud Sadjadi

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

[email protected]

Phases of Software Project ManagementSoftware Project Planning

Project Content and deliverables

3rd LectureCEN 4021: Software Engineering II

AcknowledgementsAcknowledgements

Dr. Onyeka Ezenwoye

Dr. Peter Clarke

2


AgendaAgenda

Overview of phases of Software Project Management (SPM)

Software Project Planning– Project Content and deliverables


Phases of SPMPhases of SPM

The software project management activities include:– Project planning and scheduling– Project cost– Project monitoring and reviews– Personnel selection and evaluation– Report writing and presentations


Phases of SPMPhases of SPM

The previous management activities are captured using the acronym POMA:– Planning– Organizing– Monitoring– Adjusting


POMA POMA Management ProcessManagement Process

Planning Activities

Organizing Activities

Monitoring Activities

Adjustment Activities


POMAPOMA

Models the software management cycle– Software processes model development cycle

Applies software engineering knowledge – For example

Requirements elicitationSoftware measurements


POMAPOMA

Not necessarily sequential– Activities within each category may overlap– Categories may overlap– For example, original plans may be adjusted during monitoring

and adjustment activities.


PlanningPlanning

Set of activities used to develop a plan of attack for the project:

Description of software product i.e., artifact contents and deliverables.

The Software product attributes. Project schedule. Resources needed to meet project schedule. Measurements used to gauge the status of the

project. Risk associated with project.


PlanningPlanning

Points to note: Time consuming Important phase of SPM Often rushed Even with a well conceived plan changes are

often necessary. Experience is very helpful in developing a

project plan. especially knowledge of organization.


OrganizingOrganizing

Seeks to construct a software development based on the project plan.

Activities include:

– Acquiring various skilled individuals needed for the project.

– Defining the a process and a set of methodologies 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.


OrganizingOrganizing

Issues of major concern: Personnel are properly equipped to perform their

designated task i.e., – equipping personnel include obtaining tools and preparing

facilities

– educating personnel in using tools, methodology, and metrics

Allocation of adequate financial funding. Team may include financial and personnel management. “People management” aspect of organizing is critically

important.– Morale affects productivity


MonitoringMonitoring

Monitoring focuses on: Consistently and regularly collecting measurements. Analyzing the data. Representing and presenting the data for a defined set

of reports. Making projections and making recommendations based

on the analysis of the data. Involves people management.


AdjustingAdjusting

Adjustments are often necessary due to:– Changing software requirements

– Discovery of an unfeasible design

– Lost of skilled team members

– Financial constraints

Adjustments may be made to:– Requirements

– Schedule

– Resources

– Project content

It is very important to do a thorough risk analysis during the planning stage of the project


AgendaAgenda

Phases of Software Project Management (SPM)

Software Project Planning (POMA)– Project Content and deliverables


Plan ContentPlan Content

Varies depending on the type of software project.

All project plans must address:– What is the nature of the s/w project and what

software artifacts are the desired deliverables?

– What is the overall schedule and the associated major project milestones?

– What are the required resources and their associated financial costs?

– What are the known risks and the areas that are still unknown?


Comprehensive PlanComprehensive Plan

Problem and requirements– User problems needs and wishes

Product/Project Description– Complete scope of the project i.e., all project deliverables, and a

description of each deliverable.

Product/Project Attributes– Description of the various attributes of deliverables and non

deliverables as they pertain to the goals of the project e.g., quality. Identify metrics for the attributes.

Schedule– Sequence of tasks – Identification of milestones and deliverables



Cost– Details in terms of some unit e.g., person-days, for

each deliverable– Includes expenditures – tools, travel, training,

communications Resources

– List of people needed and their skills– Complete set of tools– Special training – Software and hardware systems required



Process and Methods– Description of the overall process and methods

Risks– List of potential problems– Assessed impact– Probability of occurrence– Plan to prevent risk from turning into a real problem


Requirements Elicitation Requirements Elicitation

Before the project can be initiated, software engineers need to:

– identify the requirements of the project,

– interfaces to related systems or subsystems.

Gathering s/w requirements is one of the most difficult task of any s/w project.

The software project manager needs to provide an environment conducive to proper requirements gathering and analysis.

– Enough time and suitable skilled people


Requirements ElicitationRequirements Elicitation

Points to note:

Requirements must be understood and agreed upon by all the stakeholders.

– Not just software engineers

Not understanding the s/w requirements of the project can be very costly.

– Improper testing, quality issues

– Customer requirements not met

– Missed schedules

Consult domain experts is necessary.

The requirements document is a contract!!


Agreeing on and initiating

Reqs

Reqs Elicitation

Reqs Analysis and

Prototyping

Reqs Review

Reqs Specification

Agreeing and“Signing Off”

(as needed)

General requirements General requirements management activitiesmanagement activities


Requirements AnalysisRequirements Analysis

Involves checking that the specification is correct, complete, consistent, unambiguous, and realistic.

Correct – accurately represents the client’s view of the system.

Complete – all possible scenarios are described including exceptional behavior.

Consistent – does not contradict itself. Unambiguous – exactly one system is defined.


Requirements AnalysisRequirements Analysis

Software prototype - a s/w model created for the purpose of better understanding the requirements and the feasibility of the proposed solution.

Must have clearly specified schedules – To avoid repeated viewing and reviewing of prototypes

– Define clear entrance and exit criteria.

– Define scope of prototype activity.

– Must be agree upon by everyone.


Types of Requirements Types of Requirements

Major types of requirements:– The project deliverables– The needs satisfied by the deliverables (project)

Project deliverables– Requirements document– Design document– Source code– Executable code– Test scenarios



Project deliverables– Test cases with test data

– User guide

– Product reference manual

– Test results and quality-related data

– Process specification

– Project plan

It is important to be informed of the practices of the organization.



Project needs and their characterization– This is the area where most s/w engineers, rather than the

software project manager, should focus there energy. – The following items should be identified:– The functionality of the s/w– The nonfunctional requirements of the s/w– The interfaces that the s/w needs to interact with its users


Review and Approval of Review and Approval of Requirements Requirements

software project manager needs to ensure the first set of reqs (the deliverables) are clearly defined understood, prioritized, and agreed upon by the stakeholders.

All parties should formally “sign-off” on the deliverables. include a final review of the requirements specification

prior to sign-off.


Prioritization of Prioritization of RequirementsRequirements

Project reqs are sometimes initiated by solution providers internally.

These requirements are the most difficult to evaluate. The requirements usually initiate during maintenance. It is a good idea to have a prioritization procedure for both

internal and external reqs. Inputs from the various reqs sources are constantly

coming in to the s/w organization and being captured, possibly by an automated tool.


Development

Support

Customer

Consultant

ReqsRepository.

.

.

SoftwareProduct

ManagementBoard

List of Reqs input to the

Product Plan

RequirementsPrioritization

RequirementsSources

Requirements PrioritizationRequirements Prioritization


Prioritization of Prioritization of Requirements Requirements

Resources must be set aside for the following activities:– Regular review of inputs– Analysis of the valid inputs– Prioritization of the inputs– Response to both the accepted ideas and rejected ones– Formulation of the accepted reqs subset into actual reqs for the

product plan.

CEN 4021 Software Engineering II

Documents

Transcript of CEN 4021 Software Engineering II