Software Engineering Process Models

Directing

• A technical leader is responsible for reviewing and approving decisions made by others.
• Technical leaders are tasked with building morale and supporting staff.
• They are also responsible for monitoring and controlling projects, coordinating work with other projects, and reporting progress.
• Technical leaders are constantly striving to improve the process.

Software Process Models

• Help project managers and their teams decide what work should be done and in what sequence it should be performed.
• Act as aids to thinking, not rigid prescriptions.
• Each project will ultimately develop its own, unique plan.

The Waterfall Model

• The classic way of viewing software engineering that emphasizes requirements, design, and quality assurance.
• Engineers are expected to work through stages of development in a series of steps.
• Stages should be followed by verification and validation to ensure thorough quality assurance before progressing.
• The waterfall model discourages revisiting previous stages of development.

Limitations of the Waterfall Model

• Makes the assumption that a given stage can be completed before moving to the next stage.
• Doesn’t account for continuously changing requirements.
• Customers can’t use anything until the entire system is finished.
• No allowance for prototyping is made.
• Assumes that all requirements can be accurately gathered at the beginning of a project.

Key Features of Agile Development

• Adaptive: Adapts to new requirements as they arise. The focus is on adapting to changing needs instead of removing uncertainty.
• Empowered Teams: Project teams are generally smaller and work closely together. Team members are empowered to make decisions.
• People Centric: Focus is on using skilled individuals rather than following specific processes. Documentation is minimized, and more time is dedicated to development and testing.
• More Disciplined: The goal is first-time completion of deliverables. This requires high levels of team and self-discipline.
• Simplicity: Focus is on keeping things simple and being open to change.

Why Agile Should Be Considered?

• Benefits to the Customer: Greater customer involvement, frequent status updates, acceptance of requirements after each iteration, rapid delivery, and a guaranteed delivery timeline.
• Benefits to the Project Team: Active involvement in all stages, empowered teams, incremental development, focus on development rather than documentation, reduced time required for gathering requirements, less planning, and cost reduction due to less rework and documentation.

Agile is Difficult Since...

• It requires more testing and customer involvement.
• It has a more significant impact on management than developers.
• Managers must be open, actively participate, and empower the team to make decisions.
• Code integration is continuous, which requires all code to work seamlessly.
• Highly skilled and adaptable individuals with passion are essential.

Agile is Best Suited for Projects With...

• Frequently changing requirements.
• Teams and clients who are co-located.
• Clients who are open too much involvement and are willing to invest time.

Re-engineering

• Periodically, project managers should set aside time to re-engineer all or part of a system.
• This can range from cleaning up code to replacing a layer or refactoring a design.
• Re-engineering is typically done to enhance maintainability.

Cost Estimation

• Cost estimation determines the amount of software engineering time required for a particular task.
• Elapsed Time: The duration between the start and end of a task or project.
• Development Effort: The amount of labor needed in terms of person-months or person-days.
• To convert effort to cost, it's multiplied by the average cost of employing a software engineer for a month or day.

Principles of Cost Estimation

• Principle 1: Divide and Conquer: Break down the project into subsystems, further divide them into activities, and make individual estimates, summing them for the overall project estimate.
• Principle 2: Include All Activities: Consider all development activities, including prototyping, design, inspecting, testing, debugging, documentation, and deployment.
• Principle 3: Use Historical Data: If similar projects have been completed, use that past information as a basis for estimating.
• Principle 4: Adjust for Risk: Account for potential uncertainties, delays, or problems.
• Principle 5: Consider Productivity: Factor in likely productivity levels based on team experience, complexity, and technology.
• Principle 6: Employ Multiple Estimation Techniques: Use a variety of methods, such as expert judgment, analogy, function point analysis, COCOMO, or other techniques, and compare them to ensure a more accurate estimate.
• Principle 7: Revise and Refine Estimates: Update estimates as more information becomes available, requirements shift, or risk management reveals new issues.

Scrum Poker

• A consensus-based technique for estimating effort.
• A variation of the Delphi method.
• Members make estimates using numbered playing cards revealed face-down on a table.
• Cards are revealed, and estimates are discussed.
• Avoids the bias of “anchoring,” where the first number influences subsequent estimates.

Software Engineering Teams

• The ideal team structure and composition can vary, and here are some examples:
• Egoless Team: Also known as a “self-organizing team.” Everyone is equal; decisions are made by consensus. Best suited for complex projects with technical challenges.
• Hierarchical Manager-Subordinate Structure: Individuals report to a manager and perform assigned tasks. Suitable for large, scheduled projects where everyone is well-trained and has a defined role. However, problems may go unnoticed due to individual responsibility.
• Chief Programmer Team: A hybrid between egoless and hierarchical. A chief programmer leads and guides the project, relying on specialists for consultation.

Choosing an Effective Team Size

• There is an optimal team size for a given development effort.
• Doubling a team size doesn't automatically halve the development time.
• Teams and subsystems should be sized to minimize knowledge and information sharing.
• Team size may need to change throughout a project.
• It is generally not effective to add people to catch up on a delayed schedule.

Skills Needed on a Team

• Architect
• Project Manager
• Configuration Management and Build Specialist
• User Interface Specialist
• Technology Specialist
• Hardware and Third-Party Software Specialist
• User Documentation Specialist
• Tester

Project Scheduling and Tracking

• Scheduling: The process of deciding the sequence, start time, and completion time for activities.
• Tracking: The process of monitoring project progress against the schedule and cost estimates.

PERT Charts

• Display the sequence in which tasks must be completed.
• Nodes typically show elapsed time and effort estimates.
• The critical path indicates the minimum time needed to complete the project.

Gantt Charts

• Visually represent the start and end dates of software engineering tasks.
• Time is shown along one axis, and tasks on the other.
• Bars indicate tasks, and diamonds represent milestones (important deadlines with specific events).

This quiz covers key aspects of directing in software engineering, including the role of technical leaders and the importance of software process models. Additionally, it explores the Waterfall Model, its stages, and the significance of verification and validation in ensuring quality assurance. Test your knowledge on these fundamental concepts!