Software Project Management Exam 1

Ariane Flight 501

A rocket mission that disintegrated after 39 seconds in June 1996 due to a software exception in the Inertial Reference System, illustrating the critical consequences of software failures.

Software Exception (Ariane 501 Context)

An error triggered by an overflow when converting a 64-bit floating-point number to a 16-bit signed integer, demonstrating how unprotected or incorrect data conversions can cause system failures.

Inadequate Testing

A cause of failure when actual operating conditions are not included in test specifications or simulations, highlighting the importance of realistic test environments.

Wrong Type of Reuse

Reusing a component from one environment in another without verifying its suitability, exemplified by software from Ariane 4 failing to account for Ariane 5's faster velocity.

Wrong Design Philosophy

A design approach assuming failures result only from random hardware issues and lacking consideration for systematic errors, which contributed to Ariane 501's failure.

Software Engineering (SE)

The application of a systematic, disciplined, quantifiable approach to software development, operation, and maintenance, treating it as an engineering discipline.

The Beginning of "Software Engineering" (1968/69 NATO Conferences)

Early conferences that introduced the term "Software Engineering," emphasizing structured, engineering-based methodologies over ad-hoc development.

Software Failures

Incidents where software malfunctions lead to unintended outcomes or disasters, with some failures becoming widely known (e.g., Ariane 501) and others remaining undisclosed.

Bridge Analogy

A comparison that highlights how software development, though sharing engineering principles with physical construction, is purely logical and thus more difficult to visualize and measure.

Software Development Life Cycle (SDLC)

A sequence of phases for managing software development—requirements engineering, design, implementation, testing, and maintenance—that organizes the entire process.

Requirements Engineering

The phase in which system functions, performance, extensions, and documentation are specified, including feasibility studies and producing a requirements specification.

Software Design

The stage focused on defining the system architecture by decomposing it into components, interfaces, and interactions, emphasizing "what" rather than "how."

Implementation

The phase centered on coding and building individual components to create a working piece of software, typically using modules or classes for maintainability.

Testing

The process of verifying the software against specified requirements (verification) and validating it against customer needs (validation), ideally starting as early as the requirements phase.

Validation vs. Verification

Validation ensures the software meets the customer's actual needs, while verification checks that the software is built correctly according to specified requirements.

Release (Transition to Customer)

The project stage where the software is deemed complete and is delivered to the customer, including final checks, packaging, installation, and training.

Maintenance

Post-delivery work to correct errors, adapt the software to changing conditions, and update documentation or structures for ongoing quality and maintainability.

Corrective Maintenance

The process of fixing defects or errors found after software is delivered.

Adaptive Maintenance

The process of adjusting software to changing environments, such as updated hardware or operating systems.

Perfective Maintenance

The enhancement of software to address evolving user needs or add new features.

Preventative Maintenance

The updating of documentation or restructuring of code to simplify future modifications and prevent future issues.

Global Distribution of Software Effort (40-20-40 Rule)

A guideline suggesting 40% of effort goes to requirements and design, 20% to coding, and 40% to testing, with maintenance often outstripping all combined.

Software Maintenance Costs (High Maintenance Costs)

The observation that maintenance forms a significant portion of total software costs due to evolving requirements, changing environments, and increasing complexity.

Point to Ponder #1 ("Why does software maintenance cost so much?")

A reflective question highlighting how continuous evolution, complexity, and change drive maintenance costs higher than initial development.

Hammurabi's Code Reference (Hammurabi's Code)

An ancient Babylonian law code (~1750 BC) holding builders strictly responsible for structural failures, underscoring the ethical weight of engineering decisions.

Software Engineering Ethics (SW Engineering Code of Ethics)

A set of ethical guidelines instructing software practitioners to protect the public interest, act for clients' and employers' benefit, and maintain professional integrity.

Agile Manifesto

A foundational statement for agile development that values individuals and interactions, working software, customer collaboration, and adaptability over rigid processes and documentation.

Twelve Agile Principles

Core guidelines derived from the Agile Manifesto that advocate delivering working software frequently, embracing change, and collaborating closely with customers.

Producing Software vs. Using Software (Shift from Production to Integration)

The tendency in modern development to integrate existing components (COTS, open-source, or services) rather than build everything from scratch.

Component-Based Development (CBSD)

The practice of assembling software systems from prebuilt, reusable components to save development effort and time.

Software Product Lines (SPL)

An approach focusing on a family of related products that share common features and are built from a common set of assets to maximize reuse and reduce time to market.

Commercial Off-The-Shelf (COTS)

Pre-built, commercially available software components that can be integrated into larger systems instead of writing all modules from scratch.

Service Orientation (SOA)

A method for building applications by linking loosely coupled, network-accessible services that can be composed and reused.

Open Source (Crowdsourcing Example)

Software whose source code is publicly available for modification and distribution, leveraging community collaboration for new ideas and features.

Heterogeneity in Modern Development

The global and diverse sourcing of software components and teams, making careful coordination and integration critical.

Software Engineering Principles (Examples)

These include building for reuse, defining artifacts rigorously, using flexible processes, formally managing quality, minimizing component interaction, producing software incrementally, planning for change, documenting trade-offs, and addressing uncertainty.

Software Project Management (CSE 4322 Focus)

The discipline combining project management practices with software engineering knowledge to plan, organize, direct, and control development efforts.

"All Models Are Wrong... Some Are Useful" (Model Limitations)

A reminder that any life-cycle model is an imperfect abstraction but can still be valuable if its limitations are understood.

Balancing Act in Software Engineering

The ongoing need to balance cost, quality, time, and scope under uncertain conditions while documenting and revisiting decisions.

Summary Point ("Summary of Chapter 1")

Software Engineering is an engineering discipline addressing complexity, evolution, team collaboration, and user needs, where maintenance is inevitable and trade-offs are constant.

Software Project Boundaries

The managerial and organizational frameworks in which a project operates, influenced by policies, concurrent projects, and overarching business goals.

Information Planning

The process of documenting how a project fits into a broader business context, including data systems, policies, priorities, and stakeholder requirements.

Project Plan

A document detailing project scope, process model, organization, risks, staffing, methods, quality assurance, work packages, resources, schedule, budget, change process, and delivery.

Continuous and Adaptive Planning

The practice of regularly updating the project plan as requirements and designs become clearer, recognizing that details cannot be known upfront.

Project Plan Contents

A typical project plan includes an introduction, a process model, an organizational chart, standards and guidelines, management activities, a risk list, staffing details, development methods, a quality assurance plan, work packages, resource needs, a budget and schedule, a change process, and a delivery strategy.

Process Model

The chosen lifecycle framework (like waterfall or agile) that describes project phases, deliverables, and workflows for development and maintenance.

Project Organization

The structure that defines team roles, departments, and communication pathways, aligning with the company hierarchy and the project's needs.

Standards, Guidelines, Procedures

Formal rules and best practices that cover documentation, coding standards, quality targets, and other methods to be followed by the project.

Management Activities

The leadership tasks such as scheduling, progress reporting, budgeting, and issue resolution that keep the project on track.

Risks (Project Plan)

Potential threats to project success, documented along with risk management approaches, escalation paths, and ongoing monitoring procedures.

Staffing Plan

A schedule and description of personnel requirements, indicating the number and types of roles needed, their expertise, and the duration of their involvement.

Methods and Techniques

The processes, tools, and practices (e.g., modeling notations, test strategies) employed in requirements gathering, design, coding, testing, and other phases.

Quality Assurance (QA)

Systematic procedures (reviews, audits, tests) to ensure the project meets defined standards and user expectations.

Work Packages

Well-defined units of work that clarify deliverables and responsibilities, often found in a Work Breakdown Structure (WBS).

Resource Identification

A description of the hardware, software licenses, environments, or other assets required to successfully complete the project.

Budget and Schedule

The plan for the project's financial and timeline constraints, often tracked with Gantt or PERT charts, or Earned Value methods.

Change Management Process

The procedure for requesting, reviewing, approving, and integrating changes to scope, requirements, or other critical factors in a controlled manner.

Delivery

The final stage where the completed project is transferred to the customer, including installation, user training, and acceptance activities.

Project Control

Continuous supervision of five factors (time, information, organization, quality, money) that shape the project's performance and direction.

Managing Time

The process of monitoring progress against milestones, recognizing that budget spent does not necessarily reflect percentage of work completed.

Brooks' Law

The principle that adding more personnel to a late project often delays it further due to increased communication overhead.

Managing Information (Documentation)

Ensuring both technical and non-technical documents, including requirements, designs, and test plans, are maintained accurately, with agile approaches relying more on tacit knowledge.

Managing People

The practice of building and reconfiguring the team, ensuring clear expectations, and encouraging effective collaboration among stakeholders.

Managing Quality

The approach of integrating quality practices from the start, requiring frequent stakeholder engagement to balance quality constraints with budget or timeline pressures.

Managing Money

The process of estimating and adjusting costs, primarily tied to labor, by considering productivity factors and evolving requirements.

Continuous Assessment

The practice of measuring and reviewing project metrics (such as cost or defects) on an ongoing basis to enable proactive rather than reactive management.

Agile Planning vs. Document-Driven

A contrast between agile methods that prefer iterative, lightweight documentation and more traditional methods that rely on formal, detailed specifications from the outset.

Chapter 2 Summary

Software project management blends planning with continuous monitoring and control over time, information, organization, quality, and money, adapting project plans as understanding evolves.

Software Life Cycle Model

A structured set of phases (requirements, design, implementation, testing, maintenance) guiding software creation, used for planning, monitoring, and control.

Phased (Document-Driven) Approach

A traditional method in which each development step produces milestone documents, providing managerial oversight but limiting flexibility for iterative changes.

Waterfall Model

A linear, phase-based model requiring each stage to be completed and validated before moving on, with constrained feedback loops.

V-Model

A waterfall variant that pairs each development phase with a corresponding testing phase, emphasizing continuous verification and validation throughout.

Maintenance vs. Evolution

Recognizes that post-deployment changes reflect the system's ongoing adaptation (evolution) rather than mere fixes (maintenance).

Prototyping

Creating simplified system versions for clarifying requirements and validating assumptions, which can be discarded (throwaway) or refined into the final product (evolutionary).

Incremental Development

Delivering the software in smaller, manageable increments and revisiting requirements and design with each release to avoid a "big bang" approach.

Spiral Model

A risk-focused, iterative approach that identifies the highest risks in each cycle, addressing them before expanding the system further.

RAD (Rapid Application Development)

A time-boxed, evolutionary method that maximizes development within fixed durations, often supported by workshops and specialized tools.

DSDM (Dynamic Systems Development Method)

A leading RAD framework that fixes time and resources first, then adjusts functionality accordingly, emphasizing active user involvement.

XP (eXtreme Programming)

An agile method that promotes small frequent releases, pair programming, test-first development, collective ownership, and continuous integration.

13 Practices of XP

These include having the whole team on-site, using a guiding metaphor, planning via user stories, simple design, small releases, customer testing, pair programming, test-driven development, refactoring, collective ownership, continuous integration, sustainable pace, and coding standards.

RUP (Rational Unified Process)

An iterative, use-case-driven framework with four phases (Inception, Elaboration, Construction, Transition), supported by UML and Rational tools.

MDA (Model Driven Architecture)

A development paradigm relying on high-level models (CIM, PIM, PSM) that drive automated code generation, focusing on portability and separation of concerns.

Lehman's Laws of Software Evolution

Observations that large, real-world software systems must continuously adapt and become more complex, requiring ongoing organizational stability and management.

Process Modeling

Documenting and representing development or maintenance processes (e.g., with state transition diagrams or Petri nets) to clarify roles, tasks, artifacts, and workflow.

State Transition Diagrams (Process)

Visual representations of states and events in a process, showing how tasks transition from one state to another.

Petri-net Representation

A mathematical modeling technique capturing concurrency, synchronization, and distribution in processes, often depicting places, transitions, and tokens.

Chapter 3 Summary

Life cycle models help structure, plan, and monitor projects, with traditional approaches emphasizing documentation and agile methods valuing iteration and feedback, while large-scale maintenance is more effectively seen as ongoing evolution.

Configuration Management

A discipline ensuring that all project artifacts are systematically identified, tracked, and controlled throughout the life cycle.

CM Tasks

Four core CM activities include identifying items, controlling changes via formal procedures, recording status, and auditing baselines to maintain integrity.

Baseline

A formally reviewed and approved snapshot of a product's artifacts, which is only changed through authorized processes.

Mainline

A series of baselines reflecting different states of a product's progression.

Configuration Item (CI)

A hardware, software, or document artifact under configuration control, treated as a single entity for tracking and updates.

Codeline

A set of component versions evolving sequentially, where each new version derives from the previous one.

Version

A distinct instance of a configuration item with unique changes from any other instance.

Branching

The act of creating a new line of development from an existing version, enabling parallel changes in separate lines.

Merging

Combining modifications from different development lines into a new unified version.

Release

A specific, approved version of the software that is delivered to customers or users for operational use.

Repository

A shared system or database that stores multiple versions of software components and logs their change histories.

Workspace

A private area where a developer can safely modify files, later merging changes into the main repository.

Configuration Control Board (CCB)

A team of senior members overseeing and approving change requests to ensure each alteration to the baseline is justified and documented.