Activity 1: Report on SDLC and Recommendations

Key Components to Include in the Report

1. Definition of the Problem

o Clearly state the problem faced by Enomy-Finances.
o Include user requirements (e.g., ease of use, security features for sensitive
data) and system requirements (e.g., web-based or network-based,
infrastructure compatibility).

Example: Enomy-Finances requires a scalable, secure system to manage client

information and support staff, ensuring enhanced performance and reliability.

2. Overview of Different SDLC Models

o Discuss three iterative SDLC models (e.g., Agile, Spiral).
 Explain their key features, benefits, and drawbacks.
 Example: Agile focuses on adaptability and client feedback, while
Spiral emphasizes risk management.
o Discuss three sequential SDLC models (e.g., Waterfall, V-Model).
 Highlight their key characteristics, such as step-by-step progression in
Waterfall and parallel testing in V-Model.
o Use visuals (e.g., flowcharts or tables) to compare the models.
3. Risks in Software Projects
o Identify project risks specific to the Enomy-Finances project (e.g., budget
overruns, delayed timelines, cybersecurity threats).
o Discuss general risks in SDLC models, such as:
 Lack of stakeholder communication in sequential models.
 Scope creep in iterative models.
o Explain risk mitigation strategies:
 For example, regular stakeholder meetings, phased delivery in Agile,
or risk analysis in Spiral.
 4. Recommendation of an SDLC Model
o Choose the most appropriate SDLC model for the project.
 Justify your recommendation with supported arguments:
 Why this model suits the Enomy-Finances project’s
requirements.
 How it aligns with project constraints (e.g., timeline,
scalability, collaboration needs).
o Include:
 Benefits and Drawbacks: Highlight strengths (e.g., flexibility in
Agile) and limitations (e.g., complex management).
 Design and Development Tools:
 Examples: UML diagrams for modelling, version control tools
like Git, or project tracking tools like Jira.
 Preferred Methodology: State whether Event-Driven, Object-
Oriented, or Functional Programming is the best fit, based on the
client’s needs.

Activity 2: Feasibility Study Report

Key Components to Include in the Report

1. Purpose of a Feasibility Study

o Explain the role of feasibility studies in project planning.
o Key points to cover:
 Evaluating whether the project is viable.
 Identifying risks, constraints, and opportunities.
 Ensuring alignment with client needs and goals.

Example: A feasibility study for Enomy-Finances will determine the technical,

operational, and economic viability of the proposed system.
2. Components of a Feasibility Study
o Technical Feasibility:
 Assess if the system can be developed using the available technologies
(e.g., web-based vs networked systems).
 Example: Moving to a web-based system would require robust server
infrastructure and heightened security measures.
o Operational Feasibility:
 Determine how well the system fits the organization’s workflow and
user needs.
 Example: Staff training requirements for a new system interface.
o Economic Feasibility:
 Consider costs vs. benefits.
 Example: Implementation costs (hardware, software licenses) versus
potential cost savings from automation.
o Legal Feasibility:
 Assess compliance with regulations (e.g., data protection laws like
GDPR).
o Schedule Feasibility:
 Analyze the timeline to ensure project deadlines are realistic.
3. Comparing Technical Solutions
o Provide an overview of alternative technical solutions to meet the identified
problems.
o Use a comparison table to evaluate solutions based on:
 Cost.
 Scalability.
 Security.
 Ease of implementation.
o Example: Compare a locally hosted database with a cloud-based solution for
client data management.
 4. Assessment of Feasibility Study Impact
o Discuss how the feasibility study impacts decision-making for the Enomy-
Finances project.
o Use specific feasibility criteria, such as:
 Improved risk management.
 Better understanding of client requirements.
 Prevention of costly mistakes during implementation.

Activity 3: Presentation with Speaker Notes

1. Introduction (Slide 1-2)

 Slide 1: Title Slide

o Title: "Application of SDLC to Enomy-Finances Project"
 Slide 2: Objective of the Presentation
o State the aim of the presentation: to explore how the Enomy-Finances project
can be implemented using a suitable SDLC model and methodology.
o Mention the key points that will be covered, including stakeholder
requirements, design methodologies, tools, and security considerations.
2. Stakeholder Requirements (Slide 3-4)
 Slide 3: Stakeholder Overview
o List the key stakeholders involved in the Enomy-Finances project (e.g., Chief
Technical Officer at Enomy-Finances, internal IT team, end-users, project
managers).
o Highlight their roles and interests (e.g., CEO wants a reliable system, end-
users need an intuitive interface, technical staff want a secure and scalable
solution).
 Slide 4: Requirements Identification
o Functional Requirements (what the system must do):
 E.g., Manage client data, allow users to track investments, and display
reports.
o Non-Functional Requirements (system characteristics):
  E.g., Security (encryption of sensitive data), scalability, user-
friendliness, and performance (fast response times).

o Security Considerations:
 E.g., How the system will manage data encryption and ensure
compliance with industry regulations (e.g., GDPR).

3. Scope of the Project (Slide 5-6)

 Slide 5: Defining the Scope
o Inputs: User data, financial transactions, system configurations.
o Outputs: Client reports, transaction summaries, notifications.
o Processes: Account creation, transaction processing, report generation.
o Security Considerations: Data encryption, secure authentication methods,
access controls.
 Slide 6: Exploring Alternate Solutions
o Discuss potential alternative solutions (e.g., desktop vs. web-based
application, different database management systems).
o Highlight the pros and cons of each option based on the project’s scope and
the client's preferences.
 Example: A web-based system is preferable due to easier remote
access and scalability.
4. Constraints (Slide 7-8)
 Slide 7: Identifying Constraints
o Budget Constraints: Limited budget for initial development, ongoing
support, or infrastructure.
o Time Constraints: Deadlines for project delivery and implementation.
o Technological Constraints: Existing infrastructure limitations (e.g., hardware
requirements).
o Regulatory Constraints: Adherence to industry standards like GDPR for data
protection.
 Slide 8: How Constraints Influence the Approach
 o Discuss how the identified constraints affect the choice of SDLC, tools, and
methodologies.
o Example: The tight budget may favor a lightweight development model like
Agile to allow incremental progress, with regular reviews to ensure it stays on
track.

5. Functional and Non-Functional Requirements (Slide 9-10)

 Slide 9: Functional Requirements
o List and explain the core functionalities the system must have to meet the
needs of Enomy-Finances:
 E.g., User registration, login, transaction tracking, report generation,
etc.
 Slide 10: Non-Functional Requirements
o List non-functional characteristics:
 Performance: System should support 100 concurrent users.
 Scalability: Future enhancements should be possible without major
changes to the core system.
 Security: Must implement encryption, secure access, and user
authentication protocols.

6. Design Methodology and Tools (Slide 11-13)

 Slide 11: Chosen SDLC Model
o Discuss the selected SDLC model for the project (e.g., Agile or Waterfall).
o Justify why this model is best suited for the project considering factors like
flexibility, client involvement, timeline, and complexity.
 Example: Agile is recommended due to its iterative nature, which
supports frequent feedback from the client and allows flexibility for
changes.
 Slide 12: Design and Development Tools
o Mention the design tools chosen for the project:
 Algorithmic Tools: Flowcharts, pseudocode for process design.
 Logical Tools: Use of UML diagrams, finite state machines (FSM),
data flow diagrams (DFDs).
  Development Tools: Integrated Development Environments (IDEs)
like Visual Studio, version control with Git, and project management
tools like Jira for tracking progress.
 Security Tools: Encryption libraries, security testing tools.
 Slide 13: Methodology for Design and Development
o Outline the Event-Driven, Object-Oriented, or Functional Programming
paradigm chosen for the project.
o Justify the selection based on the specific needs of the project:
 Example: Object-Oriented Programming (OOP) is recommended to
allow modular, reusable code suitable for scalable system
requirements.

7. Risk Management and Quality Assurance (Slide 14-15)

 Slide 14: Risk Management
o Identify and discuss potential risks during the project lifecycle:
 Technical risks: Integration challenges, data migration issues.
 Operational risks: Staff turnover, changing requirements.
 Security risks: Data breaches, unauthorized access.
o Outline the mitigation strategies for these risks (e.g., regular security audits,
using version control for code, clear communication with stakeholders).
 Slide 15: Quality Assurance Strategy
o Testing and Review Process: Describe the stages of testing (e.g., unit testing,
system testing, user acceptance testing).
o Feedback Loop: Emphasize the iterative feedback process in Agile or other
SDLC models.
o Performance Monitoring: Outline how you will monitor and evaluate the
system’s performance post-deployment to ensure it meets functional and non-
functional requirements.

8. Conclusion and Recommendations (Slide 16-17)

 Slide 16: Conclusion
o Recap the main points covered in the presentation:
 Stakeholder requirements, project scope, design methodology, and risk
management.
  Recommended SDLC model and design tools.
 Slide 17: Recommendations
o Summarize your recommendation for the Enomy-Finances project:
 Recommended SDLC model: Agile or Waterfall, depending on client
preferences and project needs.
 Tools and methodologies: Object-Oriented Design with Agile
development practices.
 Security considerations: Strong encryption protocols, secure data
storage.

9. Speaker Notes for Each Slide

 Provide detailed speaker notes for each slide to explain the content verbally during the
presentation.

Activity 4: Design, Implementation, and Maintenance Portfolio

1. Design Solution
 Introduction to Design
o Purpose of Design: Describe the objective of the design process, which is to
create a solution that meets the identified requirements of the Enomy-Finances
project.
o Approach: Outline the approach to designing the solution, including how the
problem-solving process will be guided by the chosen SDLC model (e.g.,
Agile or Waterfall).
a. Algorithmic Design
 Algorithmic Design (Flowcharts/Pseudocode)
o Flowcharts: Use flowcharts to represent key algorithms and business
processes within the system.
 Example: A flowchart for user login, financial transaction processing,
or report generation.
o Pseudocode: Provide pseudocode to describe key system algorithms.
 Example: Pseudocode for account balance update after transaction.
 Slide 3: Logical Design (FSM & Extended FSM)
o Finite State Machine (FSM): Design an FSM to represent the system states
(e.g., "User Logged In," "Transaction Pending," "Report Generation in
Progress").
 Explain the states and transitions based on user input and system
events.
o Extended FSM: An extended version of the FSM may include additional
states or subprocesses based on more detailed user interactions or system
events.
b. Data Design
 Data Design (DFDs, ERDs, Data Dictionaries)
o Data Flow Diagrams (DFD): Create DFDs to represent how data flows
through the system (e.g., data inputs, outputs, processes, and data stores).
 Example: A DFD for a financial transaction module showing data
flow from user inputs to database storage.
o Entity-Relationship Diagram (ERD): Create an ERD to represent the
relationships between different data entities (e.g., users, transactions,
accounts).
o Data Dictionary: Define key data elements, their data types, and constraints
(e.g., transaction ID, account balance).
2. Implementation
a. Implementing the Solution
 Development Overview
o Outline the implementation process, mentioning the programming languages
and technologies chosen (e.g., Python, Java, C#, SQL, HTML/CSS for web-
based applications).
o Environment Setup: Describe the development environment (IDE,
frameworks, version control tools like Git).
o Software Development Methodology: Detail how the SDLC model (Agile,
Waterfall, etc.) is used throughout the implementation phase.
b. Code and Functionality Implementation
 Code Implementation
o Core Functions: Describe how the core features are coded (e.g., user
authentication, transaction processing).
o Algorithm and Logic Implementation: Show how algorithms designed
earlier (e.g., for financial calculations) are translated into code.
o Security: Discuss the security implementation (e.g., encryption of sensitive
data, secure login features, and role-based access control).
c. Integrating Data Design
 Data Integration
o Database Design and Integration: Discuss how the system interacts with
databases. For example, explain how the application communicates with a
 relational database (e.g., MySQL, PostgreSQL) to store user data and
transactions.
o Data Binding: Show how the system binds data from the database to user
interfaces (e.g., displaying account balances).

3. Testing and Quality Assurance

a. Testing Plan
 Testing Plan Overview
o Test Types: Outline the types of testing used in the development process.
 Unit Testing: Testing individual components (e.g., testing the login
module, transaction processing).
 Integration Testing: Testing the interaction between different system
components (e.g., user interface with backend database).
 System Testing: Full system testing to ensure that all components
work together as expected.
 User Acceptance Testing (UAT): Ensure the system meets client
requirements and expectations. Collect feedback from the CTO of
Enomy-Finances.
 Test Documentation: Provide details on test plans, test cases, and bug reports.
o Example: Include test scenarios for different user roles (e.g., Admin vs.
Regular User) and their corresponding access rights.
b. Refinement and Bug Fixing
 Refinement and Bug Fixing
o Describe how the testing feedback was used to improve the solution (e.g.,
fixing bugs, improving performance).
o Refinement Process: Explain any code optimization or changes made to
improve system performance or usability based on the testing phase.

4. Documentation
a. Development Documentation
 Development Documentation
o Code Documentation: Ensure that the code is well-commented to explain its
functionality.
 o Test Documentation: Include test case documents, results, and bug reports.
o Change Logs: Document any major changes made to the codebase throughout
the development and testing phases.
b. Support Documentation
 User and Technical Manuals
o User Manual: Provide a simple guide for end-users explaining how to use the
system (e.g., logging in, accessing financial reports).
o Technical Manual: Offer detailed instructions for system administrators and
technical staff on system setup, maintenance, and troubleshooting.

5. Maintenance and Updates

a. Post-Deployment Maintenance
 Post-Deployment Maintenance
o Ongoing Maintenance: Discuss the strategy for maintaining the system after
deployment. This could include bug fixes, feature updates, and performance
enhancements.
o Support Plan: Define how the system will be monitored and supported (e.g.,
regular backups, security patches, and version updates).
b. Future Enhancements
 Future Improvements and Recommendations
o Planned Enhancements: Discuss any future features or updates you plan to
implement (e.g., mobile app integration, advanced reporting features).
o Recommendations: Offer suggestions for future system improvements based
on feedback and the project’s evolution (e.g., migrating to cloud-based
architecture, improving user experience).

6. Reflection and Feedback

 Reflection and Feedback
o Reflect on the design, implementation, and maintenance process. What went
well, and what challenges did you face?
o Feedback: Discuss how feedback from stakeholders (including the CTO of
Enomy-Finances) was integrated into the solution.
 Example: Modifying the system’s security features based on feedback
about data protection requirements.
Activity 5: Evaluative Report - Detailed Breakdown
1. Introduction
 Overview of the Report: Introduce the purpose of the report. Explain that the report
evaluates the software solution developed for Enomy-Finances, assessing how well it
addresses the business needs and technical requirements.
 Briefly describe the project, its scope, and the role of the solution in the context of
Enomy-Finances’ needs (e.g., a financial management system).
 Outline the key areas that will be evaluated in the report, including the software
requirements traceability, quality improvement, SDLC model, design tools, testing,
feedback, and future improvements.

2. Analysis of Software Requirements Traceability

 Tracing of Software Requirements: Explain how the software requirements for
Enomy-Finances were traced throughout the SDLC. Detail how both functional and
non-functional requirements were handled.
o Functional Requirements: Example: Secure login, user role management,
transaction processing, reporting features.
o Non-functional Requirements: Example: Performance (e.g., system response
times), security (e.g., data encryption), scalability (handling future expansion).
 Documenting Requirements: Describe how these requirements were documented
and referred to during each phase of the SDLC (e.g., during design, development, and
testing).
 Tools for Traceability: Mention any tools or systems (like requirement management
tools or documentation practices) that ensured the proper tracking of these
requirements throughout the project lifecycle.
 Example: Describe a specific requirement (e.g., secure financial transaction handling)
and how it was consistently addressed through the design, coding, and testing phases.

3. Improving Software Quality

 Approaches to Improving Software Quality:
o Testing: Discuss the various testing strategies applied, such as unit testing,
integration testing, system testing, and user acceptance testing (UAT). Provide
specific examples of how these tests identified and corrected issues.
 o Code Reviews: Explain how code reviews were implemented to ensure code
quality and adherence to best practices. Discuss the role of peer reviews in
maintaining consistency and quality across the codebase.
o Automated Testing: Describe any automated testing frameworks used (e.g.,
unit tests using JUnit or integration tests), and how they contributed to
improving software reliability.
o Quality Assurance Documentation: Mention how testing results, quality
checks, and refinements were documented.
 Examples of Quality Improvements:
o Example 1: Describe a bug or issue that was detected during the testing phase
and how it was fixed.
o Example 2: Discuss the steps taken to ensure the system’s security (e.g.,
penetration testing for vulnerabilities).
 Tools and Techniques: Identify any specific tools (e.g., Jenkins for CI/CD,
SonarQube for static code analysis) and techniques (e.g., continuous integration) that
were used to ensure software quality.

4. Evaluation of the SDLC Model

a. Benefits and Drawbacks of Chosen SDLC Model
 Chosen SDLC Model: Specify which SDLC model was selected for the project (e.g.,
Agile, Waterfall, Iterative, Spiral) and explain why it was chosen.
o Benefits: Describe the advantages of this SDLC model in the context of the
Enomy-Finances project.
 Example: Agile (if selected) allowed for iterative development, with
feedback from stakeholders (e.g., the CTO of Enomy-Finances) at
regular intervals, ensuring the solution met evolving requirements.
o Drawbacks: List the potential disadvantages or challenges encountered when
using the SDLC model.
 Example: Waterfall might have been less flexible for rapid changes
and iterative client feedback, as it involves linear stages with limited
scope for changes once the requirements were defined.
b. Justification for the SDLC Model's Appropriateness
  Appropriateness for Enomy-Finances: Justify the choice of SDLC model for
Enomy-Finances’ project.
o Discuss how the chosen model aligns with the project’s goals (e.g., security,
scalability, flexibility).
o Example: If Agile was used, explain how this approach provided flexibility in
adapting to changing requirements and regular client feedback.
c. Impact of SDLC on Project Outcomes
 Impact on Project Success: Evaluate how the selected SDLC model impacted key
outcomes, such as meeting deadlines, staying within budget, and delivering a quality
product.
o Example: How iterative sprints in Agile helped keep the project on track by
continuously addressing client feedback.

5. Evaluation of Design and Development Tools

a. Design Tools Used
 Design Tools: Identify the tools used for system design (e.g., UML diagrams,
flowcharts, ERDs, draw.io DFDs, etc.), and explain why they were appropriate for the
Enomy-Finances project.
o Example: If you used Lucidchart for designing DFDs and ERDs, explain how
these visual tools helped communicate the system’s architecture effectively.
b. Evaluation of Design Tools' Suitability
 Suitability: Evaluate how well the chosen design tools suited the needs of the project,
compared to other potential tools (e.g., using Visual Paradigm instead of
Lucidchart).
o Discuss any advantages or limitations you encountered using the selected
design tools.
c. Development Tools and Methodologies Used
 Development Tools: Discuss the programming languages, frameworks, IDEs, and
version control tools used (e.g., Python, JavaScript, React, GitHub).
o Suitability of Development Tools: Explain why these tools were appropriate
for the Enomy-Finances project.
 Example: React.js was chosen for front-end development to build a
responsive and dynamic user interface.
 Development Methodology: Discuss any methodologies (e.g., TDD, pair
programming) that were applied in the development process.
6. Systems Investigation and Testing
a. Review of Systems Investigation
 Systems Investigation: Evaluate the investigation process that was conducted before
development, including how the needs of the Enomy-Finances system were explored
and analyzed.
o Example: How the initial research and interviews with stakeholders (e.g.,
Enomy-Finances’ CTO) helped shape the system’s design and functionality.
b. Review of Testing Process
 Testing Process: Provide a review of the testing process, including unit testing,
integration testing, and system testing.
o Example: How tests were used to ensure the system met security and
performance requirements.
 Impact on Solution Quality: Explain how testing ensured the quality and reliability
of the software solution, and how issues identified during testing were resolved.

7. Data-Driven Software Considerations

 Data-Driven Approach: Discuss the role of data in the Enomy-Finances project and
how a data-driven approach (e.g., database design, data storage, and security)
improved the reliability and effectiveness of the solution.
o Example: How the system used secure, normalized databases to manage
financial transactions and customer data.

8. Future Recommendations and Improvements

 Recommendations for Future Enhancements: Provide suggestions for future
improvements to the solution, such as additional features, performance optimizations,
or expanded functionality.
o Example: Mobile application development for customer convenience.
 Rationale for Future Improvements: Justify the need for these enhancements based
on the evolving needs of Enomy-Finances and feedback from the client.
9. Conclusion
 Summary: Summarize the key points of the report, including the evaluation of the
SDLC model, design and development tools, testing processes, and overall system
performance.
 Final Evaluation: Offer a final assessment of the solution’s effectiveness and
suitability for Enomy-Finances, including any lessons learned and final thoughts on
the project.

10. References
 References: Include all sources of information, research, and tools referenced
throughout the report using the Harvard referencing system.

Note: Reports, Speaker notes, design portfolio, and presentation slides

should be attached together and submitted as one copy.